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.

Actually I mentioned this several messages back. I don't know if you were hanging out on the CI$ forum when the fellow who worked at CBN messaged that they had concluded that the optimal method for handling ~200 users & ~50-60,000 inserts per work day was to preload the tables. WHen you want to add that many records, each of which locks the header for a fraction of a second, you get some significant slowdowns - as I'm sure you know. <g>

Even with the new auto-increment feature planned for V8 I'd still recommend an evaluation of the 'real life' needs and requirements.

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

Indeed it is. And, candidly, why the 'big iron' products will eventually prevail in these kinds of scenarios - or with some sort of workaround that is more than likely bound to fail as well.

>
>**--** Steve
>
>>>Hello,
>>>I always include NEWID() in stored procedures, and I really do not understand the fever about AutoIncrement...
>>
>>Those of us who spend a lot of time answering questions in forums like those know that there are lots of questions about this topics. For people new to VFP (whether they're moving up from FP2.x or coming from other environments), the lack of an autoincrement facility makes it harder to get started doing things right.
>>
>>I know that people on the Fox team have spent a lot of time asking members of the community how they can make it easier for newbies to get up to speed. Autoincrement is one way.
>>
>>Tamar