Mark Breen
marklbreen at gmail.com
Thu Jun 14 04:33:08 CDT 2012
Hello John, good point about the roll over value, Mark On 12 June 2012 15:18, jwcolby <jwcolby at colbyconsulting.com> wrote: > Mark, > > The problem with that theory is that the PKs are scattered "randomly" > through the numeric range. So there is no "largest number" or that number > could be waaaayyyy up in the numeric range, in fact it could be one below > the "rollover" value. > > You understand what I am saying? > > > John W. Colby > Colby Consulting > > Reality is what refuses to go away > when you do not believe in it > > On 6/12/2012 4:23 AM, Mark Breen wrote: > >> Hello Gustav, >> >> I think that SQL Server will automatically pick up at the largest number >> currently in the table and work away happily. If not, you can easily set >> the starting number for the new range using DBCC CHECKIDENT >> >> In fact, if the last random number was 547845714 you could make the next >> Identity Insert start at 6000000000 >> >> Mark >> >> >> >> On 11 June 2012 11:36, Gustav Brock<gustav at cactus.dk> wrote: >> >> Hi Arthur >>> >>> Nope. He (the client) just picked random autonumber for the IDs because >>> he >>> somewhere had read that it had some advantages and - as we all know - the >>> number should be meaningless. >>> >>> So I think I will transfer the IDs as is and then see if I can change the >>> field to straight SQL Server autonumbering. >>> Does anyone know what happens when SQL Server for a new record "meets" an >>> ID that is already taken? >>> >>> /gustav >>> >>> >>> fuller.artful at gmail.com 08-06-12 17:20>>> >>>>>> >>>>> Gustav, >>> >>> IMO this is not the best method, and not even the second or third best >>> method. If for reason you or the client doesn't like AutoNumber, that's >>> cool. I have dealt with such unruly clients in the past (c.f. my missive >>> on >>> long-lasting hardware) Back to the subject: if for some asinine reason, >>> the >>> client doesn't like AutoNumber, then present her with the alternative, >>> GUID, which according to MS's statisticians, is guaranteed to work for >>> the >>> next 70+ years. By which time I shall be dead, and therefore unavailable >>> for post-midnight fixes. Sorry, but Arthur has left the building. >>> >>> Which reminds me of a couple of websites I happened upon this week. >>> >>> "Why can't we just get a Bong?" Marijuana party of Canadia. And the other >>> one I forget. LOL. >>> >>> >>> ______________________________**_________________ >>> dba-SQLServer mailing list >>> dba-SQLServer@**databaseadvisors.com<dba-SQLServer at databaseadvisors.com> >>> http://databaseadvisors.com/**mailman/listinfo/dba-sqlserver<http://databaseadvisors.com/mailman/listinfo/dba-sqlserver> >>> http://www.databaseadvisors.**com <http://www.databaseadvisors.com> >>> >>> >>> ______________________________**_________________ >> dba-SQLServer mailing list >> dba-SQLServer@**databaseadvisors.com <dba-SQLServer at databaseadvisors.com> >> http://databaseadvisors.com/**mailman/listinfo/dba-sqlserver<http://databaseadvisors.com/mailman/listinfo/dba-sqlserver> >> http://www.databaseadvisors.**com <http://www.databaseadvisors.com> >> >> >> > ______________________________**_________________ > dba-SQLServer mailing list > dba-SQLServer@**databaseadvisors.com <dba-SQLServer at databaseadvisors.com> > http://databaseadvisors.com/**mailman/listinfo/dba-sqlserver<http://databaseadvisors.com/mailman/listinfo/dba-sqlserver> > http://www.databaseadvisors.**com <http://www.databaseadvisors.com> > >