George,

>>Beeing some who always thinks about statements to make, I've already thought about this issue. Here is my take.
>>
>>Upsizing is never an easy task. Upsizing the autogenerating key feature from VFP 7 to SQL-server is not fully possible. In VFP 8 you can add a new record in a table and having the new PK available inmediately. When using SQL-Server, you must do this either via local views or SPT. The new PK is only available whenever you've saved the record and requested the same row again from the server. The usizing process would create a difference between handling local en remote data.

>Nope, this is totally wrong. An auto-increment only creates the the PK when the record is committed, not before. This is exactly the same as SQL Server. Since both identity and auto-increment columns are designed to be surrogate PKs, there's no need for you to even have to worry about what the value is.

You're not listening. If I insert a record in a table and request the value:

APPEND BLANK IN MyTable
TABLEUPDATE(2,.T.,"MyTable")
? MyTable.Pk

This would work perfectly in with local data. However, if the data is in a remote view it does not work. What do you think happens when MyTable is based on a remote view ?

>>In VFP you can have your custom autokeygeneration routine attached to a view as PK or as any other numbering field. This seems not to be possible with the new VFP 8 incrementing key feature. If you really look at these issue carefully you'll see that those two techniques are incompatible at the detail level.


>Again, we're dealing with surrogate PKs. They they're principal purpose is to uniquely identify the record.

Come one george, I know that. This is not the issue. In many of my projects forms I use a record buffered table for the parent and several table buffered local views for entering the childs.

In these forms, I could add a parent and childs, without commiting (tableupdate) any data so that I can undo the add anytime. Since all data still is buffered, how am I ever going to relate the parent and child without knowing the PK value of the parent ? I simply can't do this with an autoincrementing feature on the table. I need them on my views and rowbuffered data also.

>If you need the keys to be meaningful, sure. But as I've said, surrogate PKs aren't.

You need to know what the PK value is whenever you want to commit both inserted parent and child data in one transaction.

Walter,