>>>>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 nNEW 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
>>
>
>Dave,
>So you would have 1 to n number of possible ID records for each table that you
>wanted to manage IDs for! That sounds like a big enough hassle that I would
>prefer to just skip IDs where the user backed out of the add. :-/

Steve,
I also just skip IDs where the user backs out, but it would appear there are some systems out there with a requirement of not skipping a single ID in the sequence!