I've been away from access for a while, and my brain has locked up. I
have a form, (mimicking a paper form) that has many checkboxes
indicated the many LOB.
It would be poor design to put all the possible value of the checkbox
in a table i.e. LOBnew, LOBValuePlan, etc. & User has to be able to
select multi values.
I created a table called LOB. Unsure as how to put it on a form, so
the results are record in the table, thining a subform, but would need
many checkboxes

On Aug 31, 8:12*pm, The T <teresaei... (AT) gmail (DOT) com> wrote:
I think you should use an additional LOB table (not the one with the
possible LOB choices) as a related table for LOB information. The
schema might look something like:

tblBusinesses
BusinessID AutoNumber
BusinessName Text
....

tblLOBChoices
LOBCID AutoNumber
LOBChoice Text

LOBCID LOBChoice
1 "New"
2 "Value Plan"
3 ...

tblLOB
LOBID AutoNumber
BusinessID Long (Foreign Key to tblBusinesses)
LOBCID Long (Foreign Key to tblLOBChoices)

Note that tblLOB can have multiple records for each business. For a
given business, querying tblLOB should show which unbound checkboxes
should get checked. When one or more checkboxes get edited (or batch
the entire set of changes using a 'Submit Changes' button), perhaps
run a delete query to delete all the checkbox values for that business
and append fresh ones to the table with a single Append query. That
would simplify the logic somewhat, but you are free to use whatever
logic passes all your software tests. Appending a 'Cartesian Query'
of each BusinessID with the LOBChoices to a table that also contains a
Boolean field to record selections could provide a way to bind the
checkboxes to a query that is limited to the current BusinessID, but
that might get difficult to maintain (but not impossible) if new
LOBChoices are added often.

I hope that helps,

James A. Fortune
CDMAPoster (AT) FortuneJames (DOT) com