"DangerD321" <da********@aol.com> wrote in message
news:20***************************@mb-m16.aol.com...
well the thing is they could select one from the menu and accidently hit
and extra key or change the numbers quite easily and it not be correct, but
still work...
my work says i need to ensure the delegate is connected to an existing
organisation, making the validation rules necessary, so please do not talk
down to me just becuase i am in school.
i would like to know how to do this anyway because i need it for another
problem
i hope 'one' can understand my predicament.....
The response was not an attempt to condescend, but the question is genuinely
a bit puzzling and there seem to be a couple of issues going on. The basis
of the database design is the tables and I can see you have at least 2.
These should be similar to:
tblOrgs:
OrgID = Autonumber & primary key
OrgName = Text
etc
tblDelegates:
DelID = Autonumber & primary key
DelOrgID = Long integer. This is the ID of the Org to which the delegate
belongs
DelFirstName
DelLastName
etc
You should enforce referential integrity so that DelOrgID must exist in the
tblOrgs. But at this point you have some design decisions to make. Is
DelOrgID required? That is, can you have a delegate who does not belong to
any organisation, or does your data model say that each delegate must belong
to one? Then what about cascading deletes, for example? Would you want to
automatically delete all related delegates if you deleted the org, or should
org deletion be impossible until all related delegates have first been
deleted?
Once these things have been sorted, we come back to the listbox. If you
have said that not all delegates belong to orgs and you only want to be able
to select those which do, then this is simple. You base you listbox on a
query with an inner join
SELECT * FROM tblOrgs INNER JOIN tblDelegates ON tblOrgs.OrgID =
tblDelegates.DelOrgID
Does any of that make sense?
Tom