The db_key is created by the engine when you SELECT a set. Newly-inserted

> rows don't have a db_key and they won't get one until after the posted
> insert is committed and the query is run afresh. It's a really bad
> idea to
> rely on db_key for a table that you have to insert to. Even if the table
> doesn't have a PK (which sounds pretty silly to me), you should supply
> all
> of the table columns that make a row unique into the KeyLinks property.
>
> If the detail set is a joined set, you still need to establish
> uniqueness. An update (or delete) has to target one and only one row
> precisely with a WHERE condition that is capable of finding that one row.
>
> In addition, if you have an application design that is trying to update
> rows that have been inserted but not committed, then you need to examine
> your design. If the only way you can see an inserted row is to shut down
> the connection, then that's a clear indication that the design is wrong.
>
> Helen
>

Thank you Helen. Not for only solving the problem. But also on guiding
me on some design. I more question. Back in my schools days, my teacher
or professor didn't tell us that a detail table has to have a primary
key, but only a foriegn key. The right one is even a detail table has to
have a primary key?

Thanks


Cheers

James