"Evils of Lookup FIelds"?

  • Thread starter Thread starter el zorro
  • Start date Start date
E

el zorro

SO I've read a little thing that warns against using the
LOOKUP feature when designing tables. Apparently its not
good to assign values to a field based on values in
another table; better to just join the tables in a query
and get your values that way.

But what about using the VALUE LIST lookup option when
designing a table? This does not reference another table,
but you just type in the list of values from which you
want the user to select. For example, I might want to
limit data for a Status field to "Approved," "Pending."
and "Denied." SO rather than creating a separate table
for these 3 entries, I just type them in to the table
design, via the LOOKUP feature. Any harm in that?
(Thanks!)
 
el said:
SO I've read a little thing that warns against using the
LOOKUP feature when designing tables. Apparently its not
good to assign values to a field based on values in
another table; better to just join the tables in a query
and get your values that way.

But what about using the VALUE LIST lookup option when
designing a table? This does not reference another table,
but you just type in the list of values from which you
want the user to select. For example, I might want to
limit data for a Status field to "Approved," "Pending."
and "Denied." SO rather than creating a separate table
for these 3 entries, I just type them in to the table
design, via the LOOKUP feature. Any harm in that?
Click to expand...

I don't think so. It's just that it is quite rare to have a list of values
that will *never* change or be added to.

If you do then fine, but you have quite a bit of work to do if you want to
add 'Revoked' for example, later on.
 
SO I've read a little thing that warns against using the
LOOKUP feature when designing tables. Apparently its not
good to assign values to a field based on values in
another table; better to just join the tables in a query
and get your values that way.

But what about using the VALUE LIST lookup option when
designing a table? This does not reference another table,
but you just type in the list of values from which you
want the user to select. For example, I might want to
limit data for a Status field to "Approved," "Pending."
and "Denied." SO rather than creating a separate table
for these 3 entries, I just type them in to the table
design, via the LOOKUP feature. Any harm in that?
(Thanks!)
Click to expand...

If you reread the rant against Lookup Fields you'll see that it is NOT
objecting to using combo boxes (whether table based or list-of-values)
for entering data. It's perfectly routine to do so, and good
practice... ON FORMS, which is where data entry should be done.

In my opinion the worst disadvantage of Lookup Fields is that it keeps
people tied to using table datasheets for data entry, rather than
moving to Forms. Forms are much more capable and controllable than
table datasheets - and you can freely use combo boxes on Forms.

John W. Vinson[MVP]
Join the online Access Chats
Tuesday 11am EDT - Thursday 3:30pm EDT
http://community.compuserve.com/msdevapps
 
I don't like value lists either. Opinions vary, but it is just as easy to
store these values in a table. Then you can give your users a form in which
they can maintain their own dropdown lists. If they do not have this
option, they must come to me as the programmer to add it, because the
information is stored in the APPLICATION rather than in the DATABASE.
Personally, I think (and EF Codd agrees) that all data should be stored in
the database and not in the application.

--
--Roger Carlson
Access Database Samples: www.rogersaccesslibrary.com
Want answers to your Access questions in your Email?
Free subscription:
http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ACCESS-L
 
Back
Top