>>>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
>
>Mike,
>
>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 :(

AutoInc clashes with Table buffering applied on parent table. One may rethink interface to avoid these cases.