>>>Fabio
>>>What happens if i add a record in the view?
>>
>>The record is added to the view's buffer.
>>
>>>Will it look for the next number in the underlying table's autoinc field?
>>
>>not
>>
>>> If yes, i hope the autoinc number gets updated in the table. In this case, what happens then if i do a TableRevert?
>>
>>disregard.
>>
>>> If not, i then have to start numbering those id's in the view manually, and i will have collisions if people enter records directly in other screens in the underlying table while somebody is working on the view.
>>
>>This is, but any collision can happen.
>>
>>You have 3 cases:
>>- first : at the client side the id is not necessary because none foreign key exists on the interface.
>>you can set id = NULL
>>
>>- second : at the client side the id is necessary because some ( not implicit ) foreign key exists,
>>but only once an id is used;
>>on this case a id is necessary to maintain the interface's data structure.
>>You can define a temporary id ( into the buffer ), this can to be a id that exists
>>
>>- third : at the client side the id is necessary because some ( not implicit ) foreign key exists,
>>but others id are used;
>>on this case a id is necessary to maintain the interface's data structure,
>>but temporary id cannot to be an admissible id.
>>You can define a temporary id ( into the buffer ), but this id has to be a not admissible value
>>( for example a negative number, the solution chosen by the VFP Team for buffered recno() )
>>
>>At the end,
>>TABLEUPDATE() disregard the temporary id and get the true ID from the autoinc field,
>>TABLEREVERT() doesn't touch the table.
>>
>>Fabio
>
>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