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