Combo box vs text box

[hiwelcome]

Hello,

I have a form full of combo boxes tied to fields in a table that work perfectly fine. However, I noticed that when going into the tables and looking at the "Lookup" tab, many of the fields tied to combo boxes on the forms have the Text Box property instead of Combo Box. I've tried switching one with no problems but my question is, do I need to do this for all of them? Will it affect functionality if I don't? And also, any idea why there's the inconsistency in the first place?

 

[Ranman256]

if you see a combo box on the form, then it is a combo box and NOT a text box.

 

[MarkK]

I don't see what is inconsistent. You can put a combo on a form, and you can define a foreign key field in a table to display linked data in a combo, but these are different solutions to different problems, and they have no affect on each other.

 

[hiwelcome]

I don't see what is inconsistent. You can put a combo on a form, and you can define a foreign key field in a table to display linked data in a combo, but these are different solutions to different problems, and they have no affect on each other.

Maybe I'm misunderstanding something on a fundamental level. For example, I make a form with three combo boxes on it, and tie them to a respective field in a table (and form's record source is said table). But when I look at the properties of these three fields in the table, all three may be text data type, but on the lookup tab, one may say "Text Box" under Display Control and two of them say "Combo Box" with Row Source Type, Row Source, etc etc. I'm just wondering why this is happening and what I can do to fix it, or whether it needs fixing at all.

edit: Whether it says "Text Box" or "Combo Box" under Lookup does not appear to have any effect on combo box-form functionality. Hope I made the inconsistency more clear.

 

[MarkK]

Doing something on a form does not cause a change to a table. Tables and Forms are distinct things.

A table is a warehouse for data. Mostly people will argue that data in a table should be stored raw, and that you should not define lookup fields in tables. Keep them as pure and simple as possible, and use other available tools to display and process that data.

Use a query to select data from a table. Consider SQL as simple as . . .

SELECT * FROM Table1;

. . . and if you want Combobox lookup fields, define them in that query.

Then display that query in a form. When you create a form with Access wizards, the controls will be inherited--at first--from the definition of the query or table on which the form is based. So if you create a form based on a query that has a combobox lookup, a combobox is created on the form by default. But editing a control on a form never pushes that definition back to the table or query. And editing the display control in a table or query never broadcasts that change to user interface elements that use that table or query as a data source.

Hope this helps define for you what the different object types do, and how edits to one type will never automatically make changes to the other. The only case where table or query configuration modifies a form is at creation time--and only if you use an Access wizard. Other than that, all edits to objects are local to that object.

 

[hiwelcome]

That does help very much. Thanks for the explanation!

 

[MarkK]

You bet, Cheers,