combo boxes on forms vs look ups tables

[Frankie]

OK, I have learned a bit about the "bad" look up tables, and how they an eventually mess some things up. However, the nice thing about them is that if you have the multiple forms, with same combo boxes options, if you refer to look up tables, all you need to do to update both combo boxes is update the one table. If I create combo boxes and manually enter them (instead of look ups), will I have to go to multiple forms to update them all? Seems redundant. Am I missing something?

[Edgar]

I think what people often find bad is lookup fields, not lookup tables. Lookup tables are good, they're tables to get information for your combo boxes or listboxes, whereas a lookup field, which is something you configure at table design, instead of form design, may present a bunch of issues, as mentioned in here:
http://access.mvps.org/access/lookupfields.htm

I don't use lookup fields, I don't like datasheet views either, so I don't use any of them, but the evil one is the lookup field. I prefer to use forms.

Forms good. Lookup tables Good. Form combos Good.
Datasheet views ok. Lookup fields bad.

[June7]

There is no "vs" involved. Comboboxes use lookup tables. Lookup tables are not "bad" - lookup fields are "bad".

Related thread https://www.accessforums.net/showthread.php?t=88688

[Micron]

Frankie, this distinction was made in post 5 of your other thread.
I see nothing wrong with datasheets per se. There are cases where other form views are better but to label them as bad is - well, just bad.

[Frankie]

ok... ah... no one has answered my question. Would I have to update ALL forms that have same combo box if I entered them in manually. I had to get rid of look ups to make my report right. Or is there a way to have look up tables just go to forms, with unbounded fields for query search criteria from said form? But would reports still return number instead of text? I guess I'll have to play around with it and see myself... but first question is still:

Would I have to update ALL forms that have same combo box if I entered them in manually.

[June7]

Properly constructed report will show text, not ID numbers. We have described two methods to accomplish.

I answered in post 33 of your other thread: "Easier way is to use lookup table as source for combobox list. Need to add a new item - just enter a record in table, otherwise, yes will have to modify forms."

Any and all comboboxes using lookup table as RowSource will automatically reflect any new items in table. A hard-coded ValueList will not.

[Frankie]

Properly constructed report will show text, not ID numbers. We have described two methods to accomplish.

I answered in post 33 of your other thread: "Easier way is to use lookup table as source for combobox list. Need to add a new item - just enter a record in table, otherwise, yes will have to modify forms."

Any and all comboboxes using lookup table as RowSource will automatically reflect any new items in table. A hard-coded ValueList will not.

I tried both of those methods... neither worked. So there is a setting somewhere or something that is off. I cannot find it. I did however get it to work by getting rid of relationships and list tables (as look ups) and manually entering option in combo box directly on form. It works like a charm. I did then go back and try go make a table that lists options for combo box for form, NOT for table input, then I made the look up table the "data" for a combo box on form only, and bound that combo box to table record for input data. The combo box on the form them began to only list numbers, not text. So unless someone walks me through the exact process and points out exactly the jam in my cogs, I am stumped. However, as I said, I fixed it by removing look ups altogether. I will just have to manually add options to form combo box as needed. Thanks for your help. I appreciate it. Eventually, some day, I'll get it.

[June7]

Well, both methods have been used by us with your db and they worked.

I gave explicit instructions in posts 24 and 28 of your other thread on how to modify your posted db to demonstrate the combobox approach.

Mike even gave you a revision of your db with the non-combobox report approach. Did you examine it?

If your manually built comboboxes are not working, then yes, properties are not correct. Would have to see what you did. Critical would be:
RowSource
RowSourceType
ControlSource
BoundColumn
ColumnCount
ColumnWidths

[Frankie]

well, yeah, i think that is what it is. we would have to see. I was able to get it working on my end, so I am happy as a clam.

[June7]

That throws the premise of "doing it right" out the window. Are you the only user of this db? No one else will ever manage it?