Jim – You're doing it the right way. I have lookup tables for every item that needs commonly selected items. As you mentioned earlier, it provides more accurate spelling and limits choices. Every foreign key usually requires a lookup table for a form.
For instance, I have an application that stores all information on each application our company uses. One of the items is the server name associated with the app. Server details are filled in on a server form. The main App form has a sub form for a many-to-many server relationship. An app can have several servers. The user fills out the app info and selects the server from a combo box. It shows the server name but the table stores the server ID as a foreign key.
I was referring to my own combo boxes with the tables as the record source and it was clear that that meant too many tables to have in the design, I suppose.
But I do not know of any other way to get a select list of choices into a combo box without using lookup tables. So I stayed with my design and ignore his comments.
Was the developer perhaps referring to lookup fields, rather than lookup tables? Most developers agree that lookup fields are poor design.
A developer recently told me that using lookup tables is bad design. I argued that it is not possible to have drop downs on a form without having some data associated with the dropdown so users do not make spelling errors for one. it gives users limited choices, so they do not have the wildest things typed.
I began thinking how would anyone have combo boxes without lookup tables? What do other developers do especially SQL backend users?
Posted by: "Bill Mosca" <firstname.lastname@example.org>
|Reply via web post||•||Reply to sender||•||Reply to group||•||Start a New Topic||•||Messages in this topic (7)|