Good news (sort of); I talked to somebody at MSFT and he cleared the air a bit. I will share with you what he said:

- The TF 272 option won't work in Azure

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

It isn't ideal for sure, but I'm no longer concerned about hitting an int limit.

Hopefully that helps some people here.

	Erstellt von Mary Macdonald vor mehr als 11 Jahre

Notiz am SQL Azure Identity Jumping, erstellt von Mary Macdonald am 15/07/2015.

SQL Azure Identity Jumping