That was a big reason why it took me longer (in the beginning) to understand and implement the true relational db normalization model since it was easier to rely on the lookup fields that others created (and then I created), as a means to link data from other tables.

I’ve seen it happen to many others also, and many have gained a false sense of confidence in being able to build more advanced databases because of the lookup field link to other tables. Fortunately for me, I understood that I didn’t know enough to proceed into deeper waters until the time came.

But cheap imitation practices do delay learning correct practices, as visual conceptualization is a big part of learning and grasping true practices. Just because Johnny can drive the car around the driveway, doesn’t mean he is ready for the highway. Same goes for “relational” database theory.

Maybe someone is wondering what I am talking about. Well, for example, many dept managers gain the false belief that just because someone can present them a database that is “RELATIONAL” — has data from multiple tables being linked (RELATED) through lookup fields from other tables, that that alone proves that one understands relational db theory, when it is not the case at all.

I’ve seen it many times over, many dept Access database hobbyists come in with a supposed relational database, and thus the boss surely thinks they have arrived at the breakthrough ability that others haven’t figured out in being able to make a db relational. Now, this may sound crazy, as I am not talking about dummies here, but a dept full of engineers in various other disciplines.

Obviously, advanced users will know how to develop a db with or without lookup fields, but not everyone does. So, it is my opinion that lookup fields ought to be left for novices learning early Access database operations, and not for developmental databases.

As for the other points about lookup fields being evil, I can’t answer that, as I have not tested out those hypotheses or those rebuttals besides this one point I am making. But I know this one point to be a FACT, as I have seen a number of databases in advanced stages of cancer where chemo couldn’t even help them – all because the “lookup field” gave Johnny a license to drive when he was not ready!

For example, even in cases where an end user with no knowledge of the underlying database is the primary operator / owner of the data, a database belonging to a business may care more about business continuity than user experience.

Given that business continuity has many aspects; database portability (lookup fields are not common to all database standards), avoidance of assumptions (in your article you wrote “you have to assume that someone writing queries is not the target of the end-user abstraction provided by lookups” – this is quite some assumption for a mission-critical DB for a corporation), not to mention the fact that multiple people maintain and develop large databases owned by businesses and they may have different views on lookup data and may not assume that a given table uses such functionality – given the above, surely it’s best to avoid using lookup fields when there’s an alternative?

Okay, I know your rebuttal will be that businesses tend not to use MS Access for this very reason, and that MS Access is designed for the end user to make more simple databases rather than big business, but why encourage users (who, let’s face it, may tweak with the database as well) to get into bad habits? And why assume that your little one-man database might not eventually develop into something that *could* become mission critical one day?

In your example, the field spcFullName contains the foreign key, not the data itself, so if you append ” (Chair)”, you’re appending it to the key, which is why you get “2 (Chair)”.

You need to add the table that the lookup refers to (let’s say it’s called FullNames) to the query, and replace spcFullName with Fullnames.FullName. Your calculated field will then display correctly.

They have never caused me an issue, and although I read the cited article, I happily ignored it because I recognised that none of the objections applied to my design.

For my latest project, I have done without them, as I intend to upsize it. This article is making me suspect that I have added time and complexity to the design job unnecessarily, which is rather annoying.

When placing my lookup field into iif function, which appends text to the field value, I get the id value (instead of the name value). Consider.

Problem: Append text” (chair)” to Full Name field based on role field value
Solution: Use iif function to append text to field via Expression Builder
Assumption: John Doe is the committee chair

Control group: =IIf([Role]=”Chair”,[spcFullName],[spcFullName])
Result: Jane Doe, John Doe, Jack Doe

Test group: =IIf([Role]=”Chair”,[spcFullName] & ” (Chair)”,[spcFullName])
Result: Jane Doe, 2(Chair), Jack Doe

As you can see from the control group, the correct full name value is displayed regardless of whether or not the person’s role is ‘chair.’ As you can see in the test group though, appending text to the full name field (where person’s role IS ‘chair’) resulted in function printing the lookup id (not the name) value.

Any idea why the lookup field’s ID is displayed when text with appended via iif function?

Thanks for your input!

make a table called Customer.
make a table called Order that has a CustomerID as a lookup field

now query Order and sort by CustomerID
a developer gets exactly what he expects: a column sorted numerically.
A user gets something completely confusing: the Customer names are NOT sorted alphabetically. The customer sees alphabetic names in the CustomerID column, but they are NOT sorted alphabetically the way he asked.

Do NOT use look up fields