Form based on table/query to select a recordset ID for inclusion as a FK in table (1 Viewer)

KyleB

Registered User.
Local time
Today, 11:01
Joined
Sep 14, 2001
Messages
71
Trying to use a form based on a table to choose a recordset of values, and pick the ID of that recordset to include in another table as a foreign key.

I am not sure how to even search for what I'm trying to do, though I've tried all the variants I can think of anyway.

The idea being that there are a set of values that are associated with each other, and generally found in conjunction with another set of data. So Table 1 contains data such as this, though this is greatly simplified from the numerics that are actually stored in these fields:

FooID Field 1 Field 2 Field 3 etc, etc...
1 x y z
2 d y z
3 x y q
4 x r P
.
.
.

This data is then associated with the information in table 2, and rather than repeat fields 1-whatever in table 2 I want to use the FooID in table 2 to store the link to all of the subsequent field data. Normalization as I understand it in other words.

I cannot figure out how to pull the table 1 data into a datasheet form and allow someone to choose one of the lines of data, store the FooID into an unbound text box, or some other method, and then run an update query on table 2 to update a field with the FooID for the 12-72 records that are in that table.

Would this make more sense as a combo box in a single form? I've been trying to do this with a datasheet, but I think I'm too limited in appending a check box to an individual recordset this way, or at least I've not managed to get it to work so far anyway.
 

JHB

Have been here a while
Local time
Today, 20:01
Joined
Jun 17, 2012
Messages
7,732
Have you looked at subforms?
 

KyleB

Registered User.
Local time
Today, 11:01
Joined
Sep 14, 2001
Messages
71
I'm not sure I can see how a subform would change the issue, it would only allow me to display the table data, as I do now, but it still doesn't let me simply display a list of the values and let the user choose one line of factors to use. Thanks for the suggestion though.

The more I think about it, the more I think a combo box would be the preferred method. It's possible the list could get long in the future, which would be annoying to pick through to find exactly the right combination of factors. I don't see an easy way around it, other than 14 or 15 tables of factors, and associated combo boxes, thereby making the user choose each one, which is a whole other level of tedium.
 

Users who are viewing this thread

Top Bottom