Very "easy" question regarding parent child relationship

[ST4RCUTTER]

Here is the scenario. I am creating a database to track tasks. On the main table, tbl_tasks are the following fields:

tbl_tasks
*TaskID [autonumber]
TaskName [Text]
CreatedBy [Text]
RequestedBy [Number]

tbl_requestor
*RequestorID [autonumber]
FirstName [Text]
LastName [Text]
ContactNumber [Number]

Now, the child table is called tbl_requestor. The idea here is to store the requestor information only once for any given requestor. So this should be a 1-to-many relationship with the many side being on tbl_tasks. This requires a PK on the child table tbl_requestor and a non-unique FK on the parent table. In this case, RequestorID is related to RequestedBy. The problem becomes, you can't create a child without a parent. How should I go about setting up the form so the Child gets created first, and then the PK value is assigned to the field RequestedBy before the insert of the parent record? Is tbl_tasks really the "parent" in this relationship?

 

[pbaldy]

I'm not a normalization expert, but I wouldn't really think of these as having a parent-child relationship. Orders to order details is a parent-child relationship. I see this as more of a lookup table. In any case, since requestor is the one side of the relationship, it would more appropriately be thought of as the "parent".

 

[tokoloshi]

Try the file I just created for you.

Pop me a question if it doesn't make sense.

T

 

[Pat Hartman]

I would use the name "RequestorID" in the task table rather than "RequestedBy" because it makes the relationship clear without having to look at the relationship diagram.

Use a combobox with a not in list event to choose requestors. If the requestor is not in the list, open a popup form to collect the requestor information. In the AfterUpdate event of the popup form, requery the combo on the original form and place the newly assigned RequestorID value there so that it is pre-selected.