Correlating two combo boxes not difficult. You reference the first as a
parameter in the RowSource property of the second, e.g.
SELECT CaseType FROM CaseTypes WHERE AppealType = Form!cboAppealType ORDER
BY CaseType;
Note that you can use the Form property to refer to the form here rather
than a reference to the form by name. In the AfterUpdate event procedure of
the cboAppealType combo box set to Null and requery the cboCaseType control
with:
me.cboCaseType = Null
Me.cboCaseType.Requery
In the form's Current event procedure requery the cboCaseType control:
Me.cboCaseType.Requery
By "from 1 of the 3 queries" do you mean you have three separate queries,
one for each possible appeal type? If so this is unnecessary as you can se
from the above.
One caveat: if you are using 'natural' keys as in my example above then
this will work fine in either single form view or continuous form view. If a
numeric 'surrogate' key is being used however, e.g. CaseTypeID in a hidden
first column of the combo box, then the above will only work satisfactorily
in single form view as, in continuous form view, rows where the AppealType
differs from the current row will have the case type blanked out as the
numeric key value corresponding to the displayed text value will not be
present in the rows returned by the RowSource property; the value will still
be there in the underlying table, however.
Another thing to note is that if these controls are bound to columns in the
form's underlying table you are almost certainly introducing redundancy as
CaseType implies AppealType. Consequently the table exhibits a transitive
functional dependency and is therefore not in Third Normal Form. For ways of
handling this see:
http://community.netscape.com/n/pfx...yMessages&tsn=1&tid=23626&webtag=ws-msdevapps
While this uses geographical data, the local administrative units in my
area, the principle is the same.
Ken Sheridan
Stafford, England
