Walter,

>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.

>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.

>As for upsizing, One that always works is having your own key generation routine: Don't fix it, if it aint broke.
>
If you need the keys to be meaningful, sure. But as I've said, surrogate PKs aren't.