I have this table setup at SQL Azure
CREATE TABLE [dbo].[Sl](
[ID] [int] IDENTITY(1,1) NOT NULL,
[PublicId] [uniqueidentifier] NOT NULL,
CONSTRAINT
This is a known issue. There are two related items reported on Connect. This one is actually closed as by design, but I don't think the engineer who left the comment really understood the issue:
http://connect.microsoft.com/SQLServer/feedback/details/743300/identity-column-jumps-by-seed-value
This (earlier!) bug is active:
http://connect.microsoft.com/SQLServer/feedback/details/739013/failover-or-restart-results-in-reseed-of-identity
The latter has one interesting workaround, and others that raise my eyebrows. The primary workaround on the suggested dupe would be fine for your own box, but good luck running a trace flag in Azure (or creating a startup proc as one of the connect items suggested). Using a SEQUENCE with no cache may be a viable option, but you should validate that the trade-offs are worth avoiding gaps in a meaningless, surrogate number. The other answer there suggests issuing a CHECKPOINT after every insert. Ouch.
In the end, if you want a sequence without gaps, stop using IDENTITY
- that's not what it was designed to do.