>>Hi Kevin
>>
>>When you try to build an app which has a parent-child-grand child relationships, the grandchildren need to know which child they belong to. So beyond a single table or parent-child relation, you must generate some kind of key, in your app.
>>
>>I say generate keys all the time so you have a consistent practice. Don't make them sequential as they don't have to be. Don't tie them to a single table. Don't ask the back end for them - cause that gives the backend more to do, both in generating and sending the key(s) back to you.
>
>Hey Mike you kind of scare me. Don't ask the back end for the keys? Yep that line pretty much makes the hair on the back of my neck stand up.
>
>This is SQL Server so you create a SP that that inserts data into top level table, and returns the key back. That value is then used in next SP for level two's insert giving back the value(s) you need to take to level three.
>
>You bind it all into a transaction and your pretty darn safe.
>
>I do batch processing on about 150,000 new header transactions that make about 4 to 8 transactions per row depending on what type or tans it is. This is processed in roughly 1.5 hours. We deal with banks so having continous, sequential keys is very important.

As long as the keys are unique is that not all that matters for relational integrity? Why does it matter where they come from?