I suspect your code did something in the wrong order. For instance, if you didn't actually use a System key table. See the problem:

1. User #1 seeks record with last key in Customers table. (Key 99)
2. User #1 locks record
3. User #2 seeks record with last key in Customers table. (Key 99)
4. User #2 begins locking (but it takes a couple tries perhaps...)
5. User #1 gets key value and adds one, and unlocks record.
6. User #1 Adds a record to Customer (Key 100)
7. User #2 record lock succeeds (on record #99!)
8. User #2 tries to add another record with key = 100.

So you need an actual System table which contains the next available key. And if you already were using this strategy, check your record locking strategy. Are you sure you locked the System record, AND updated it, before unlocking it? Even if you aren't sure whether the key will really be used, you have to increment the next available key value. Otherwise you get a similar problem to the one above. And it's no big deal if keys get skipped when users abandon records.

I mean, the ubiquity of your key value errors suggests a programming mistake to me more than a windows buffering nightmare.

Adam

>I was working with an app running at 70 locations, 3-5 concurrent users per. Appx. 10-200 transactions per location per day. Had problems with corrupt (sequential) primary key , on average, 3-20 times a week total.