>May I ask a kind of novice question about this to autocrement or not debate?
>
>Many of you have developed -- or obtained -- classes to handle keys; they have been tested, tested, and tested, and so they are as rock-solid and free from bugs as one can ever expect. So what will be the advantage of having a new VFP autocrementing feature? Perhaps, as some of you have suggested, new VFPers will like them. So why not include a class (not a native feature) in the VFP software? The advantage of classes, as I am learning, is they can be subclassed and customized to meet our individual needs. FWIW, I've tried the Access autocrementing feature and am using the class way in VFP. As I novice, I much, much prefer the current VFP way.

Each of the techniques requires an extra table and some locking on it, so it introduces more complexity (synchronization was mentioned) and potential deadlocks in a heavily congested network.

Native support for the autoincremented PK would do the same thing at the dbf's header, which introduces almost zero overhead - this header is already locked as needed, so it'd be just one more integer inside it, read and written along with the other stuff in the selfsame block. Faster, more reliable, and almost no overhead, plus reduced network traffic, fewer locks and file handles used.

And if it breaks, don't blame me - it's MS this time :)

OTOH, if it's not in the table header, but in the DBC, I think I'll stick to my methods. Metadata shouldn't be updatable by the end user.