But then, I could
just open the query, rather than even opening the table, which I guess is
the
point after all. Sorry I'm rambling; I'm "thinking out loud" here.

Correct. And, in fact, if you do things right..then you will open a nice
form, or whatever. Think of using a application...you don't want to "guess"
what table to open etc...but provide a nice menu that opens up a nice form.
Users don't care about tables...and stuff like that. Of course..now that you
are starting to wear the developers hat..then a different view of things
needs to be taken.

I'm sorry, but I have to ask: If the normal and recommended way is to
store and display the [Supplier] ID# in the [Products] table, WHY is the
sample
database written to display [Supplier] Names in the [Products] tables,
which is the ABnormal and NOT recommended way? This is confusing to us
newbie's

Ah, the got the above wrong!!

If the normal and recommended way is to store
and display the [Supplier] ID#

No, the normal and recommend way is to start the ID, but display the
suppler name!!! Your users will NEVER EVER see the internal ID. So, store
the id, but display the suppler name.

To make such a control on a form, you simply use the wizard, and drop in a
combo box into the form. The wizard will guide you thought the rest of this
process..but just make sure the ID is the first field you select for the
combo box..and the 2nd field the "text description", or supplier name in
this case. The result will be a combo box that searches, and displays by
suppler name..but SAVES THE ID in a appropriate (long integer) field.
Ms-access will thus do (solve) this common solution to your problem.

Also, I'm afraid I don't quite follow. 1) Are you implying that I should
be
looking at the form within the table somehow?

For you end users, you most certainly do want a nice form, and a nice comb
box solves this for you.

However, if you must display and "open" the data table directly (which is
not
a good idea for end users), then you have to use the query builder, and join
in those additional fields from the suppler table that you want. And perhaps
you want a few more then just the suppler name to be available in this
query.
Once you make this query, you save it, and then as you stated open this
query in place of the table..and you will see the "text" suppler name in the
table, along with any other fields that you want from the "other" table.

2) Are you saying that the
combo box in the form, which displays Supplier Names to choose from for
data
entry, but stores the ID in the table, is itself a kind of query?

It does in fact behind the scenes use a query. However, just let the combo
box wizard make it for you. You can take a look at the settings for the
combo box, and you will note that some query is used "inside" the combo
box...but you don't have to make this query if you use the wizard.

3) I don't
understand what you mean by "set the ID." 4)

You got the above idea right. When I said "id", I meant suppler id. However,
for consistency sake, 100% of my tables use "ID" as the key field, and then
I never have to "guess" as what the primary key id used for a table is.


The table is apparently not MEANT for viewing;
it's just a storage closet from which to pull out whatever I want to view
somewhere else. Did I finally get it?

Yes...and of course you "can" use a query in place of a table anyway..and it
will/can display data from other tables.


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.members.shaw.ca/AlbertKallal