Combo box show only id's in a form

[plavookins]

I created a form based on my table. There is one column “racunopolagaci” in a table where I used query in order to see names instead of id's ..see picture

When I open my table I can choose list of names under that column instead of id’s. But when I create form based on that table and after that create combo box (find a record based on the value OPTION ….) I can only see id’s but not list of names.

Is there a way to fix it?

 

[Galaxiom]

Check out the ColumnCount, BoundColumn and ColumnWidths properties of the control on the form. Normally the Wizard takes them from the table but the derived column in your table field has probably confused it.

BTW. Most professional developers don't release a database with table lookup fields. They can be handy in the initial stages of form setup but they should be removed later. And as you can see in this case it didn't help in the form design anyway.

 

[plavookins]

it seems ok (columncount, boundcolumn...). I need more concrete resolution to the problem.... thanks anyway

 

[CBrighton]

Use the ColumnWidths property to hide the first column.

e.g. set it to 0cm;5cm to hide the first column and make the second 5cm wide.

As lond as the BoundColumn isn't changed it will still have the Id as the .value but will display something that makes more sense to the user.

 

[plavookins]

I have already done so but the same results....... I uploaded database, look at the form "Monitor-final " and combo box "racunopolagac1". It only displays id's of the racunopolagac...

 

[Galaxiom]

The row source of the combo is incorrect. It is dutifully retrieving the value of the field as it should. You are just expecting to see the lookup value as displayed in the table.

The error is an excellent example of why professional developers eschew table lookups.

 

[boblarson]

Don't use lookups at table level!!!

I would highly suggest NOT USING LOOKUPS AT TABLE LEVEL. This is why:
http://www.mvps.org/access/lookupfields.htm

This is the main problem with things is that you are using lookups at table level when you should use them on FORMS and not in tables on fields.

 

[plavookins]

and what is the resolution to my problem in my case? Besides that what to use instead of lookups?

 

[Galaxiom]

It is a little hard to be sure due to the foreign language but it looks to me like the racunopolagac1 combo should have the same rowsource as the racunopolagac combo.

 

[plavookins]

That is correct, these two combobox should have the same list values. besides that what is the recommedations to use instead of lookups at the table level...
thanks for help

 

[Galaxiom]

what is the recommedations to use instead of lookups at the table level...

Not use lookups at table level. Just change to the Display Control setting back to TextBox.

The problem with table level lookups is the developer does not see the actual value of the field. It might be OK while the original developer works on it at first but eventually even they forget. When a new developer takes over the maintenance it is impossible.

Removing table lookup does mean that you have to manually construct the combo properties on the forms because the Wizard doesn't do it for you based on the table lookup. However it avoids confusion. With sufficient experience this is a trivial issue anyway.

I don't use the Wizard for form design as it only makes very simple bound forms. Placing and configuring the controls is insignificant compared to the coding of the command, interaction and validation logic of the form so it make very little difference to the whole job.

Once one combo is designed it is easy to copy and paste then modify the properties as required. Where a combo occurs on multiple forms the clipboard can be used to paste it to the new form.

 

[plavookins]

Thank you for your explanation and help Galaxiom.

 

[plavookins]

I explored some microsoft databases. For examples this one I attached. Look at the table Cases. There are 5 lookups in that table. This table needs information from others tables. I don't see other way to resolve it but lookups. I suppose that microsoft will use something else if it is better way. Correct me if I'm wrong.....

 

[Galaxiom]

This table needs information from others tables.

No table ever "needs" information from other tables. Tables have a single purpose and that is to store data.

Tables are not intended to present data. Presentation is done in Forms and Reports where lookups in combos and listboxes are perfectly acceptable.

However when a developer uses lookups in tables it disguises the true nature of the data. That is exactly why you expected your combo to display a name when it fact it was retrieving a numeric field.

 

[plavookins]

Did you see the microsoft table I attached? Table Cases pulls information from others tables via Lookups. I really don't understand now. What is the other way in table Cases to pull that information like \Assigned to, Caller , Opened by etc...

 

[stopher]

Did you see the microsoft table I attached? Table Cases pulls information from others tables via Lookups. I really don't understand now. What is the other way in table Cases to pull that information like \Assigned to, Caller , Opened by etc...

I fully understand your frustration here. The fact that MS has chosen to allow lookups in tables does make the explantion very confusing.

But everything that other members are saying is right. You don't need a lookup in your table because the user will never get to see the table. Instead you can happily put the lookup in the form. The lookup in the form will still store the key for the value being looked up which is all that is needed.

So the main table should only need to store the lookup key. Later if you need to reference the lookup value, the you can use a join query to relate information in your main table with your lookup tables. Edit: I don't mean remove the field. I mean change the field from a lookup to a standard text box.

So the lookup in the table is entirely redundant. You can easily prove this to yourself by removing it in the example you provided. You will find that the combo in the form still works fine and the lookup key is stored correctly in the main table.

Do feel free to keep questioning if you don't get it because if you haven't understood then the chances are that others readers won't.

hth
Chris

 

[plavookins]

I now see you edited your post and it is clear to my about changing from lookup to standard text box.

Should I create query after that which comboboxes on forms will pull information from ?



thanks for help. It was very helpful

 

[Galaxiom]

Should I create query after that which comboboxes on forms will pull information from ?l

The combo RowSource is the query that converts the value in the table to the displayed value. This is essential for the combo to be able to return the bound value.

Another way that can be used for read only is to include the lookup in the RecordSource query so that it returns the viewed value to a textbox. The slight down side of this is the longer viewed value is handled for each record instead of the ID.