>Hi Daniel,
>>Are you telling me that you don't have your copy procedures down pat and that you don't even test the tables you've copied?
>That's what I'm telling you.
>
>>Furthermore, are you telling that your custom AutoIncrement procedure doesn't handle this "problem"? Maybe it's time to refactor it...
>I'm all ears. If there's a key in the table that's larger than the value in the Keys.DBF, what would you do to check for that? SELECT MAX(PK)?

That's what I do, but only once per app launch. My newid() has a check on "we have visited this key", namely alias.keyname is stored in _screen.cKeyList property, and I calculate the max() if it's not there.

>Based on the way you work and your typical projects you may not care for auto-incrementing keys in the data engine. I'm surprised, but I'll get over it. My opinion, (and I'll have to ask my friends theirs) is that is a very helpful feature indeed.

It is, simply because it's done low-level, somewhere in the table's header or so, so it's in a block which is already read, already has the locking mechanisms in place and generally does all the neat homework under the hood, and you don't have to worry about the stuff from the above paragraphs. While I may think that my newid() is nearly perfect (or let's say sufficiently perfect), I still know that that doesn't work perfectly in all of the situations. Native support is always better.