>[...] I could not believe when I first started using VFP- where is the autokey field type?

I used FoxPro for years before looking at Access. Then I was embarassed that something so simple and obvious was there in this incredibly inferior tool, and not in my "pride and joy", FoxPro. And still not in FoxPro today...

>I haven't seen [a problem] yet. I have an app [producing lots o new records at once]. Since VFP locks the table header during an insert, and the developer can explicitly lock the pk table while incrementing the key, [etc.]

I just want to echo this. I've been using this scheme for years, and it's worked beautifully for me, too. But to make it work, you have to be sure the PK table's record(s) is/are locked, the key value obtained, the new record inserted into the main table (and children into child table(s) as applicable), then the PK table's record(s) unlocked, in that order. (In my scheme, each table has a record in the PK table, and when a record's being added, only that table's record is locked in the PK table. Erik seemed to say he was locking the whole PK table, but I may have misinterpreted.)

Anyway, if you have "library" routines which you know handle all this correctly, (or classes now), I don't see any reason to call the approach "suspect". It's as completely reliable as any other FoxPro anti-contention strategy, if done properly. And it's fairly simple.

The only thing I'm about to change in my strategy is that I always used to use short character strings for PKs, using base-36 (digits from zero to Z) because you can get huge numbers of IDs into short strings that way, and it seemed efficient before the existence of integer fields. Now that there are integer fields, it will be more efficient to use them, not only in terms of storage space, but I'll no longer have to use my base-36 number-incrementing UDF to get the next ID.

Well, I guess I've rambled on long enough now ...