After inserting the data via sql script that had
SET IDENTITY_INSERT [dbo].[table] ON
...
SET IDENTITY_INSERT [dbo].[table] OFF
the identity seed has increased by 10,000
I have tried running reseed
dbcc CHECKIDENT ('vendors', 'reseed', 57439)
but I get the error saying the DBCC command 'CHECKIDENT' is not supported in this version of SQL Server.
How to stop in the future this problem?
I found this post on the web.
The behavior (reseed) is by design, but has been acknowledged internally as less than optimal and a request has been made (again, internally) to change the behavior. This may or may not happen.
The reseed is triggered by instance bounces, which are covered by the SLA. They are mostly patches to the OS or SQL Azure itself.
The most important point was that, chances are, we will never hit the int limit. I think we all are forgetting (at least I did) that SQLAzure is not like SQL Server; there are very real limits in place, specifically total db size (150 gigs). He also said there is a max row limit per table of 10 million records, but I'm not finding documentation of that on the web. Assuming that is correct, even with jumps of 1000k, we would still be safe. And yes you could also switch to a bigint if you hit the int limit before the total db size limit. His point was simply that we will run out of room before we hit the int limit.
The Limits on SQL Azure could change, but I guess the point is you can get the large gaps if the SQL instance crashes.
