posted 13 years ago
Mike's right: unless you have a reason to do otherwise, just let your auto-increment processing set your ID. This should ensure that nobody gets duplicate IDs, but of course the ID itself is a surrogate key i.e. just an arbitrary but unique number.
If you have to avoid gaps in your ID sequence, then implicitly your ID has meaning i.e. it is not just an arbitrary surrogate key, so you need to write your own code to maintain it, because you want it to follow your own rules instead of just being an arbitrary unique number.
You will need to think about a number of issues here:
How do you identify the next available value from the data table e.g. how do you write your code to fetch "3" if you already have IDs 1, 2, and 4?
How do you cope with the situation where two different users ask for a new ID at the same time?
How do you check for and handle duplicates in this situation e.g. do your users want to see error messages because somebody else used the next ID first?
etc.
This is a lot of work and can be quite fiddly to get right in a transaction-safe, thread-safe manner. So make it easy on yourself: use the auto-increment mechanism and don't worry about what the actual value is.
No more Blub for me, thank you, Vicar.