Hi Naomi

>>>I was thinking about something like that, e.g. put, for example, a parent record negative recno() (since new records are added with negative recno if table buffering is in effect) into the child table and wait for the table update to replace child with the actual key, but it sounds quite complex.
>>
>>Very!
>>
>>I know lots of people believe autoinc is a good thing. However, you're running into difficulties with only a simple parent-child relationship. It gets harder with parent-child-grandchild.
>>
>>I'm starting to believe that showing simple examples is misleading people into thinking that these examples are the correct way to do things. Autoinc keys may be popular as a result. I'm starting to wonder if they're the best answer.
>>
>>Here's an alternative. SQL Server gurus are discussing pros and cons of using GUID as primary keys. That is because the key can be generated by applications and middle tiers with a very high degree of uniqueness. That frees the database server from generating keys, letting it only store and retrieve data.
>>
>>GUIDs are bigger than integers and are not the fastest choice. People are trying to deal with performance issues while retaining the other benefits. That sounds like a good thing!
>>
>>http://sqljunkies.com/Article/4067A1B1-C31C-4EAF-86C3-80513451FC03.scuk
>>http://msdn2.microsoft.com/en-us/library/ms189786.aspx
>>http://www.informit.com/articles/article.asp?p=25862&seqNum=1&rl=1
>
>I'm going to research your links later on, but right now I already have database designed as well as application 75% completed, so switching to a different way for PKs is not really an option :(

I don't believe it's as big a deal as you think. You're already using autoinc. Just change the types of those fields to char 16. Find a routine to generate a GUID. Remove the autoinc feature. Set the default value for the PK field to generate the GUID.

The existing keys will still work. You could pad them all with 0s if you want. New keys will be GUID. All you then do is generate the PK in your views during adds. You copy the parent PK to the child records during adds of those. Then you can even go down to grandchild and great grandchild relations.

Something to consider, eh?