>>>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. :-/