referencing a combo box from a table

S

sakool

I'd like to reference a column that is not the primary key stored in the
table. Can you reference a combo box in a table like you can when working
with forms?

Thanks for your help.
 
M

MacDermott

Perhaps you could explain a bit more about what you're trying to do.
It's generally better to use tables to store data and forms to display it.
 
S

sakool

I haven't used access in a while and I used to create combo boxes in forms
but it is an option now in table design so I went with that. But I'm trying
to create a concatenated string using values from a field with a combo box
and it is giving me the stored value (primary ID from the lookup table) I
used to reference the combo boxes from forms in my expressions to use the
column property but now what do you call the combo box in a table, are they
named?

Thanks
 
J

John Vinson

I haven't used access in a while and I used to create combo boxes in forms
but it is an option now in table design so I went with that. But I'm trying
to create a concatenated string using values from a field with a combo box
and it is giving me the stored value (primary ID from the lookup table) I
used to reference the combo boxes from forms in my expressions to use the
column property but now what do you call the combo box in a table, are they
named?
Click to expand...

They're named "Lookup" fields, and - if you insist - you can use the
Lookup tab on the field properties at the bottom of the screen.

However, most serious developers avoid this misfeature like the plague
it is: see http://www.mvps.org/access/lookupfields.htm for a critique.

Your table should CERTAINLY not contain concatenated strings or other
derived data. Such fields should exist only in Queries, or on forms or
reports.

Table datasheets should be (in my opinion) used ONLY for design and
debugging - not for data presentation or editing. Microsoft is making
(again, IMO) unwise choices encouraging the use of datasheets for
other purposes, but these changes are causing inefficiency and
confusion more than they are creating benefits.

John W. Vinson[MVP]
 
G

George Nicholson

The "combo box option in Table design" is no more than specifying the
default control type for that field when it is subsequently placed in a form
(it's a design convenience, not data storage). You should still be able to
reference it the same way, with the Column property:

ComboControlName.Column(0) refers to the first column of the current
selection. Column(1) refers to the 2nd column, etc.

"Hidden" columns (i.e., those with widths set to zero) are included in the
column count.

If you are trying to reference the non-bound column outside of a form, I
don't think you can. The field only has one value. The combobox doesn't
really exist in the table, it only exists when you use that field/control on
a form. Yeah, the combo shows up in datasheet view of the table, but it
really isn't part of the table structure itself, just your current view of
the table.
 
S

sakool

thanks for clearing that up, very helpful

George Nicholson said:
The "combo box option in Table design" is no more than specifying the
default control type for that field when it is subsequently placed in a form
(it's a design convenience, not data storage). You should still be able to
reference it the same way, with the Column property:

ComboControlName.Column(0) refers to the first column of the current
selection. Column(1) refers to the 2nd column, etc.

"Hidden" columns (i.e., those with widths set to zero) are included in the
column count.

If you are trying to reference the non-bound column outside of a form, I
don't think you can. The field only has one value. The combobox doesn't
really exist in the table, it only exists when you use that field/control on
a form. Yeah, the combo shows up in datasheet view of the table, but it
really isn't part of the table structure itself, just your current view of
the table.
Click to expand...
 
Top