Hi steve,

>Well there's that, plus the fact that coding an Autoincrement that can handle fast concurrent inserts is a real feat in VFP. I haven't followed the whole thread, but I'm surprised I haven't seen this mentioned.

>Any autoincrement procedure that doesn't explicitly lock the keys table and/or patiently wait for its explicit lock will eventually fail. In a data entry intensive system with more than say 20 concurrent users, this is a real problem.

Not the whole key table has to be locked if you're sure that concurrent insertions of new keys cannot occur. IOW, if the possible keys are already in the keys table, a record lock will do perfectly.

Though I agree that in a database with many inserts the good old strategy can form a bottleneck it has technical advantages in that it also works perfectly for inserting new records in local and remote views. For situations where the key value in views have to be known (for example when both parent and childs are entered in local or remote views), the native autoincrement feature becomes virtually useless, because you'll only know the keys until you've saved and requeried the views. But since you probably need the keys in order to know what to requery you've completely lost the the connection between what you've entered and what is stored in the database.

So, yes the autoincrementing feature might have a performance advantage, but might also cause problems when talking about either local or remote views.

Walter,