MS Server - внезапный взбрык автосчетчика

[Blondy]

Добрый день!

У меня в тестовой таблице со студенческими декларациями первое поле Declaration_ID : автосчетчик (Identity). Заполнила 10 значений через Insert Into - все работало нормально и все добавилось, автосчетчик нормально оттикал. И вдруг ни с того, ни с сего - автосчетчик перестал увеличиваться, и не добавить ничего - ни Insert, ни вручную вбив в таблицу.

А ограничение на это поле Unique - просто криком кричит - мол, должны быть в поле уникальные значения и все. Можно конечно Unique отключить, но ведь до этого все нормально добавлялось, и проблема не в ограничении, а в автосчетчике.

А как "починить" счетчик? И с чем связаны подобные выкрутасы?

[Аватар]

Это что-то из разряда мистичного. Покажите как вы создавали таблицу и автоинкриментное поле. Тип поля случайно не NUMERIC(1,0)?

[Stilet]

И вдруг ни с того, ни с сего - автосчетчик перестал увеличиваться

У-у-у было у меня такое
Причина мегабанальна и мегатупая (по краймей мере с моей стороны была) - я разрешил пользуну вставлять в автоинкрементное поле значение. Т.Е. вернее разрешил пользователю выполнять INSERT в мою таблицу.
Незнакомый с структурой пользователь вписал в эту команду внос поля, которое у меня было автоинкрементным, и дело было в том что значение в это поле пользователем вносилось не по порядку а вразбор, лишь бы было уникальным.
После чего получился казус - при вносе новой записи, без указания автоинкрементного поля СУБД ругалось, что мол такое уже есть - и действительно такое уже было.
Посему пришлось запретить пользователям работать INSERTом, и написать свою хранимою процедуру вставки и контроля вставляемых данных.

Так что, блонди, проконтроллируй, может у тебя там в БД автоинкрементное поле случайно поимело значения не по порядку, где-то может дырка образовалась.

[Аватар]

Stilet, а каким образом можно INSERT-ом вставить в автоинкриментное поле, если не пользоваться SET IDENTITY_INSERT ... ON? Какие-то еще другие возможности в MSSQL есть?

[Stilet]

SET IDENTITY_INSERT ... ON?

Хм... А вот это то я и не смотрел тогда...
Это ты верно подметил, видать лоханулся я где-то с этим параметром, или случайно выключил...
Впрочем в любом случае хранимая процедура вставки оказалась эффективнее, я не жалею.

[Blondy]

Дорогой Аватар, я прошу прощения за молчание - просто реальная жезнь требует моего пермонентного присутствия в прямом эфире)))


Вот как создавалось поле:

CREATE TABLE Declaration
(declaration_ID INT IDENTITY (1,1) PRIMARY KEY NOT NULL, 
student_code CHAR(6)NOT NULL,
first_name VARCHAR (30) NOT NULL,
last_name VARCHAR (50) NOT NULL,
 и т.д. )

А данные я вносила через:

INSERT INTO Declaration
(student_code, first_name,  last_name)

VALUES 
('234567 ', 'Ivan', 'Petrov' ,   и т.д. )

То есть поле с счетчиком даже не затрагивалось никаким образом.

[Stilet]

А данные я вносила через:

Ану открой менеджер, и посмотри что в таблице фактически. Нет ли чего необычного для этого поля? Триггеров не было?

[Blondy]

Сейчас гляну))
Куда мне до триггеров))) Мы такого пока не проходили)))))

Видим следующее:
1) То, что видим до добавления: первой строчки уже давно нет, она была тестовой, и после ее удаления все прекрасно добавлялось

2) Добавляем Insert-ом и слушаем, как среда ругается

3) Добавляем вручную и также слушаем ругань

[Stilet]

Не... Где-то ты еще чегоенто крутанула лишнего...
Хорошо бы посмотреть полный скрипт базы, создания, обьявления, внесения и пр...

[Аватар]

Blondy, если еще глючную таблицу не удалили (а скорее всего именно этим и закончится) интересно посмотреть, что вернет следующий запрос:

SELECT IDENT_CURRENT('Declaration') AS Current_Identity

Инструкцией DBCC CHECKIDENT ... в случае чего можно воспользоваться для установки нового текущего значения автоинкриментного поля