I wrote my routine prior to AutoInc functionality, but still prefer to generate my own

Basically you have a table with the name of the ID, and the ID generated
In my case the ID name is unique, but if it is not you can include the tablename also to make it unique if necessary

Make a procedure/method that accepts a parameter for the ID
search for that ID in the table, if not found, add it to the table with your default start value (I use 10000000, just for ascetics)
If found, lock the record, bump the value, unlock the record, return new value

I don't really think about it much because it's built into my data object
In my case if I send a record to my data object without a uniqid, it calls the function and generates it automatically and passes back the value,

Your welcome to my code snippet, but it's not difficult to code, and mine may not be generic enough for your use

Good luck
>Hi Robert,
>
>Would you share your approach to generating IDs?
>
>TIA,
>
>Alex
>
>>A Guid is 16 Bytes, an Integer is 4
>>I think the index would be faster with the integer, size on disk smaller, network traffic less
>>I use my own variation on method 3, but not worried about wrap around because my tables don't demand it
>>
>>But your correct that a Guid is a good choice for SQL/Replication/Etc
>>
>>Bob
>>>Like I said, if you never plan to use replication or offline mode, integer PK may be a good choice.
>>>
>>>Unless you plan to have tables with millions of records, I don't think that the size of GUID should be such a big deal.
>>>
>>>>Thanks for the response. Problem with GUID is size, of course.
>>>>
>>>>What do you think of option 3? Rick Strahl favors that and I respect his knowledge.
>>>>
>>>>>I personally prefer GUID as PK. Easy to generate, no duplication possible, work with replication and offline mode and easy to upgrade to SQL Server.
>>>>>
>>>>>>I need to decide what to use as PKs for some new free tables. As an example one case involves three tables: Groups, Group-Dates, and Group-Date-Members. The alternatives considered are:
>>>>>>
>>>>>>1. Use multiple fields as index. In some cases it seems natural because the fields involved have known values. It seems that it would be more difficult to write generic code in the classes.
>>>>>>2. Use autoincrementing integer field as PK. Is simplest but I am afraid that if at some future time the next key value is somehow altered up or down problems will follow.
>>>>>>3. Some other scheme to calculate integer PKs which offers the possibility of wrapping around and using index values that remain unused. It allows you to freely throw away index values before committing transactions.
>>>>>>
>>>>>>What is your experience with autoincrementing integers as PKs?