No, you actually don't!
If your "other" table gets a name, an "age" and a "gender" saved, then
someone has a birthday (or a serious operation), you will have to find all
the tables in which you've stored those pieces of information and update
them.
If you already have a table that contains students' names, you'll only need
to store the rowID in your "other" table to indicate which student. And if
your table of students contains a date of birth, you will be able to use a
query to dynamically determine (calculate) an "age" whenever you need it --
no need for updating! I'd probably store [gender] in that same students
table, and only there.
Good luck!
Regards
Jeff Boyce
Microsoft Office/Access MVP
>I have a form that contains a combo box and two text boxes (among other
> things). When the user chooses a name from the "students" table the other
[quoted text clipped - 8 lines]
> thank you in advance
> victor
visidro - 29 Nov 2007 19:23 GMT
Thanks Jeff, I see what you mean.
Then, how do I capture and store the rowid, I do have both tables linked.
thanks
victor
> No, you actually don't!
>
[quoted text clipped - 29 lines]
> > thank you in advance
> > victor
Jeff Boyce - 29 Nov 2007 20:35 GMT
Victor
One way would be to have a form based on (a query based on) the "other"
table. In that form, use a combo box bound to the PersonID (rowID) field in
the "other" table (this is the foreign key that points back to the Person
table row). The combo box's RowSource is the Person table, hiding the
Person/RowID and displaying the name (this makes it easier for the user to
find the right person).
Regards
Jeff Boyce
Microsoft Office/Access MVP
> Thanks Jeff, I see what you mean.
> Then, how do I capture and store the rowid, I do have both tables linked.
[quoted text clipped - 43 lines]
>> > thank you in advance
>> > victor
visidro - 30 Nov 2007 17:48 GMT
Thanks for your help Jeff I'll do that.
victor
> Victor
>
[quoted text clipped - 57 lines]
> >> > thank you in advance
> >> > victor