Forms & Tables with Combo Boxes

Hi: I have a form with two comb boxes, each combo box address a small table.
Do I need a subform with the second comb box? If not what is the rule of
thumb regarding tables to comboxes? These are not queries.
Thank You
Frank

If your data in the tables has a one-to-one relationship, like one salesman,
one product, you don't need two tables. If the data is one-to-many, one
salesman many products, then you do need two tables and you need one mainform
and a subform. The mainform for the one side and the subform for the many
side. Then, what are you trying to do with the combos? Search? Look up?
--
Milton Purdy
ACCESS
State of Arkansas


"Frank" wrote:

Hi: I have a form with two comb boxes, each combo box address a small table.
Do I need a subform with the second comb box? If not what is the rule of
thumb regarding tables to comboxes? These are not queries.
Thank You
Frank

On Mon, 5 Apr 2010 13:38:12 -0700, Frank
wrote:

Hi: I have a form with two comb boxes, each combo box address a small table.
Do I need a subform with the second comb box? If not what is the rule of
thumb regarding tables to comboxes? These are not queries.
Thank You
Frank

A combo box is not data. It's a *tool* for displaying data. I'm not sure what
you mean by "address" a small table!

The way a combo works is that it allows you to view data in its Rowsource
(which might be a list of values or more commonly a query). You can use a
Table as the rowsource but if you do so the order of records in the combo is
unpredictable. When the user makes a selection from the combo box, it will
(usually) store one field from the selected record into the Control Source, a
field in the form's recordsource.

If you want to edit or add values into the rowsource, you can use VBA code in
the combo's Not In List event, or you can create a form bound to the combo's
rowsource table. It's also possible to simply open the table upon which the
combo is based as a table datasheet and edit the data there, but that's very
limited and generally not recommended.

Could you explain how you're using the combos, and what your expectations are?
--

John W. Vinson [MVP]

"John W. Vinson" wrote:

On Mon, 5 Apr 2010 13:38:12 -0700, Frank
wrote:

Hi: I have a form with two comb boxes, each combo box address a small table.
Do I need a subform with the second comb box? If not what is the rule of
thumb regarding tables to comboxes? These are not queries.
Thank You
Frank

A combo box is not data. It's a *tool* for displaying data. I'm not sure what
you mean by "address" a small table!

The way a combo works is that it allows you to view data in its Rowsource
(which might be a list of values or more commonly a query). You can use a
Table as the rowsource but if you do so the order of records in the combo is
unpredictable. When the user makes a selection from the combo box, it will
(usually) store one field from the selected record into the Control Source, a
field in the form's recordsource.

If you want to edit or add values into the rowsource, you can use VBA code in
the combo's Not In List event, or you can create a form bound to the combo's
rowsource table. It's also possible to simply open the table upon which the
combo is based as a table datasheet and edit the data there, but that's very
limited and generally not recommended.

Could you explain how you're using the combos, and what your expectations are?
--

John W. Vinson [MVP]
.
Let me explain my self; :Address was the wrong word in my first post!
I have form which uses a table called "Vehicles" and two combo boxes. Each
combo box has a table. Example: One of the tables is called "cars" and the
other table is call "trucks". When I open the form a go the the field call
"cars" the combo box appears and allow me to select the "car" that I want and
puts the car in the "Vehicles" table, and the "trucks" combo box does the
same thing. The person
entering the data will not be allowed to edit the data. If the person
entrering the data can edit the data, then this person will not take the time
to ask a question, about the data,then this combo box table will be full of
useless data.

How many combo boxes can be used with a form?
If I need a subform why?

On Thu, 8 Apr 2010 13:11:02 -0700, Frank
wrote:

Let me explain my self; :Address was the wrong word in my first post!
I have form which uses a table called "Vehicles" and two combo boxes. Each
combo box has a table. Example: One of the tables is called "cars" and the
other table is call "trucks". When I open the form a go the the field call
"cars" the combo box appears and allow me to select the "car" that I want and
puts the car in the "Vehicles" table, and the "trucks" combo box does the
same thing. The person
entering the data will not be allowed to edit the data. If the person
entrering the data can edit the data, then this person will not take the time
to ask a question, about the data,then this combo box table will be full of
useless data.

Again:

A combo box IS NOT FULL OF DATA.

A combo box just *displays* data from a table. The table could be full of
useless data, if you don't do something to prevent it!

I'm totally not understanding your table structures. A car is a vehicle; a
truck is another type of vehicle; an SUV might be considered either a car or a
truck depending on how it's used. What are your Tables? How are they related?
Are you copying data from the Cars table and storing it redundantly in the
Vehicles table? If so why? If not, what ARE you doing?

How many combo boxes can be used with a form?

Probably up to 255, though I can't imagine any reason to do so.

If I need a subform why?

That question simply makes no sense to me. Subforms are useful for depicting
one to many relationships... but I don't understand your tables or their
relationships, so I have no idea if you need one or not.

Just to summarize: the usual function of a combo box is to allow you to select
one value of one field from a table (the combo's Row Source), and store that
value into a different field in a different table (the form's Recordsource
table, and the combo box's Control Source). For instance, your Vehicles table
might contain a field for the MakeID; you would have a table of Makes (with a
MakeID primary key and a Make, for example "Toyota", "Ford", "Rolls Royce").
The combo would let you update the MakeID field in the Vehicles table with a
choice from this table.
--

John W. Vinson JVinson *at* Wysard Of Info *dot* com
--

John W. Vinson [MVP]