>>If you are concerned about making the ID numbers tight with no gaps, then
>>structure your new Id table like this:
>>
>>TYPE NUMBER
>>
>>NEW 000564
>>SALVAGE 000563
>>
>>When you go to add a new ID, FIRST search for a SALVAGE type...If found() Lock
>>it, use it, deleted it. If its NOT found(), search for a NEW type...lock it,
>>increment it, unlock it.
>>
>>And no matter what...If the save falls through, Insert the unused ID number
>>into the table as a SALVAGE type.
>>
>>In otherwards...The salvage type will always hold FAILED ID numbers...and you
>>will always use them first.
>
>Mike,
>
>What would happen if you have say three users all start adding a new record and
>all three end up cancelling the adds? I don't see how your structure would
>support multiple IDs to salvage. Am I missing something?

Steve,
(it took me a little bit to see this but) I believe Mike is saying that the newID Table would have two fields: (idnumber) TYPE and (new ID) NUMBER. The TYPE field would indicate whether the associated NUMBER was NEW or SALVAGED. There would probably only be one record of type NEW and multiple records of type SALVAGED. For the situation you propose above lets assume there are currently no SALVAGED records in the newID table, and the NEW record contains NUMBER 1001. Each user requests and gets a NEW ID number, and each time the NEW NUMBER record is incremented afterward. User1 gets ID 1001, user2 gets 1002, user3 gets 1003, and the NEW NUMBER is set to 1004 in the newID table. Each time a user cancels their add, a record is added to the newID table with a SALVAGED type and the ID number that was canceled. The table would look like:
NEW 1004
SALVAGED 1001
SALVAGED 1002
SALVAGED 1003
The next user to request an ID from the newID table would get the first SALVAGED ID. Once the SALVAGED IDs are used up, the NEW ID is again used (right Mike?).
Dave