>I have not run into repeated IDs in any of my apps, but because you are, you should really look at the second table method and use it. It is a better way of doing it, especially if you ever have to upgrade from tables to a true client/server. I know that my way will not work in a true client/server setup. I am trying to teach myself the client/server way and hope to redo most of my programs, eventually, to client/server.

Actually, this is not a client-server issue, it's a network and locking issue. We've had this problem in 1989, and it hasn't vanished. We only have better ways of solving it now.

The reason Moses is having duplicate keys is timing in a network situation. First version, with buffering:
- user A gets a new key, let's say it's 1001. But he doesn't do a tableupdate(), so
- user B needs a new key. Since A hasn't saved, the last key in the table is still 1000, so B gets 1001 as well.
- when they both do tableupdate() (explicitly or by moving the record pointer in row-buffering situation), we have two records with the same key.

Without buffering, the save is supposed to be immediate, but the above may still happen because of network delays. Fox may have flushed its buffers immediately, but it doesn't mean that each version of Windows out there will notify user B's instance of Fox that the buffer is dirty. User B may be still looking at a slightly obsolete version of the table. The network may fix this automatically within a few milliseconds - but once in a while you have an user B who requested a new key during one of them milliseconds.

That's why we all have a pk.dbf, keys.dbf or whatever, where we store the keys for each table that needs them, and nobody writes into that table without locking before and unlocking after.

True, there may be skipped keys (user C got the key, but closed without saving - user D will get the next key regardless of the fact that C's key is used nowhere), but at least they are unique.