SQL 2005 SP3 CU1 - появились пропуски в полях с автоинкрементом

После установки SQL 2005 SP3 CU1 замечена странная и неприятная вещь:
Если в таблице есть некластерное ключевое поле с автоинкрементом, а так же составной кластерный индекс из нескольких полей, включающий ключевое поле + есть внешний ключ, то при добавлении записей в такую таблицу иногда появляются пропуски в поле с автоинкрементом!!! Раньше такого не замечалось, у кого какие мысли?

Пример:

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Table2](
[C1] [int] IDENTITY(1,1) NOT NULL,
[C2] [smallint] NULL,
CONSTRAINT [PK_Table2] PRIMARY KEY CLUSTERED
(
[C1] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

CREATE TABLE [dbo].[Table](
[C1] [int] IDENTITY(1,1) NOT NULL,
[C2] [int] NOT NULL,
[C3] [smallint] NOT NULL,
[C4] [int] NULL,
CONSTRAINT [PK] PRIMARY KEY NONCLUSTERED
(
[C1] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

CREATE CLUSTERED INDEX [IX] ON [dbo].[Table]
(
[C2] ASC,
[C3] ASC,
[C1] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Table] WITH CHECK ADD CONSTRAINT [FK_Table_Table2] FOREIGN KEY([C2])
REFERENCES [dbo].[Table2] ([C1])
GO
ALTER TABLE [dbo].[Table] CHECK CONSTRAINT [FK_Table_Table2]
GO

Пропуски в identity могут быть всегда. Начиная с 7.0. Потому что при отмене транзакции значение identity не возврщается в состояние до транзакции

Укажите, пожалуйста, строку в доке по MS SQL,
в которой сказано, что identity обязан выдавать новые значения без пропусков...

Дело в том, что отмены транзакции не возникает, специально тестировал на свежесозданной таблице... ??? Все равно так и должно быть?

Sergios

Дело в том, что отмены транзакции не возникает, специально тестировал на свежесозданной таблице... ??? Все равно так и должно быть?

ага

А еще странно, что сам инкремент иногда бывает не 1 и не 2, а 5 или 7... ???

Sergios

Дело в том, что отмены транзакции не возникает, специально тестировал на свежесозданной таблице... ??? Все равно так и должно быть?

Как это интересно вы тестировали наличие/отсутствие отката транзакции, работающих с одной таблицей с помощью другой?

Если MS SQL работает согласно документации, какие тогда проблемы, я никак не пойму...

Гавриленко Сергей Алексеевич,
Тестировал просто вводив всегда корректные значения, в монопольном режиме. Или я чего то недопонимаю? Ошибок то при вводе данных не было... ???

Sergios

Гавриленко Сергей Алексеевич, Тестировал просто вводив всегда корректные значения, в монопольном режиме. Или я чего то недопонимаю? Ошибок то при вводе данных не было... ???

Т.е. у вас с таблицей работает один пользователь в монопольном режиме вводя всегда корректные данные?