Dhruti Ramani <dhrutiraman..ahoo.com> wrote:
> ya. I had that toDepPk checked in TypeToken. So I just created both
relations from scratch so there is no "toDepPk" checked and it seems to be
working now.
> Thanks a lot for pointing out this.
>
> Does any body have any documentation to read about this "toDepPk"? I think
this is really important issue and I saw so many questions posted here about
it.
Here's my understanding of it:
If you have a master table and a dependent detail table (like EMPLOYEE and
EMPLOYEE_ADDRESS), and you want them to be linked with the same primary key,
then you mark the relationship from EMPLOYEE to EMPLOYEE_ADDRESS as
"toDepPk".
This means that EMPLOYEE can exist without EMPLOYEE_ADDRESS, but
EMPLOYEE_ADDRESS cannot exist without EMPLOYEE.
Furthermore, the primary key for EMPLOYEE_ADDRESS will be copied from
EMPLOYEE. It will not be auto-pk-generated, nor will you need to set it
manually when a new EMPLOYEE_ADDRESS is created.
I think that toDepPk needs to be marked any time you have a primary key in
one table that's the same as a primary key in another table. For instance,
if you have a two-field join table where both fields are a compound key,
then both keys are dependent primary keys. However, if you have a
three-field join table where one field is a meaningless primary key, and the
other two fields are foreign keys (but not primary keys), then you do NOT
mark them as dependent primary keys.
If you reverse-engineer your schema, the modeler seems to figure all this
out for you.
To make it easier to remember, there's a reverse-relationship called
"toMasterPK" defined for DbAttributes. In some ways, I think it's
unfortunate that toMasterPK wasn't the dominant relationship as I think most
people think in terms of toMasterPk rather than toDepPk (I know that's what
caused me a lot of problems -- I thought toDepPk actually meant toMasterPk).
Hope this helps.
-Mike
This archive was generated by hypermail 2.0.0 : Tue Jun 21 2005 - 10:59:16 EDT