Установить максимальное значение для столбца идентификаторов в SQL SERVER 2005

Question

Я занимаюсь разработкой Windows-приложения (с использованием Visual Studio 2008, Sql server 2005). Я должен поддерживать информацию в журнале. У меня есть столбец личности. Работает нормально. Но теперь значение столбца идентификаторов равно 172. Опять при попытке войти я получаю сообщение об ошибке:

Нарушение Primarykey pk_userLogId не может вставить повторяющиеся значения в object'dbo.UserLog '. Заявление было прекращено.

Когда я закрываю диалоговое окно с ошибкой, я все еще могу использовать приложение, но журнал пользователя не поддерживается.

Что я должен сделать, чтобы избежать появления этого сообщения об ошибке?

Есть ли способ установить максимальное значение для столбца идентификаторов?

пожалуйста, помогите мне! Заранее спасибо!

Answer 1

EDIT:

Мой первоначальный ответ был неверным, потому что он основывался на неправильном понимании схемы таблицы журнала. В связи с тем, что Шитал позже опубликовал эту схему (и я понял, что имя столбца было UserLogId, а не UserLoginID ...), эта гипотеза опровергается.

Таблица журнала, следовательно,

CREATE TABLE USERLOG 
( UserLogId int identity (1,1) CONSTRAINT pk_UserLogId primary key, 
  UserName nvarchar(50) not null, 
  LogInTime datetime CONSTRAINT dft_LogInTime default getdate() 
) 
--ADDING LOGOUT TIME ALTER TABLE USERLOG ADD LogOutTime datetime

делает вопрос ОП более загадочным ...

Как получить условия нарушения PK с помощью столбца идентификаторов? (если только параметр INDENTITY_INSERT для этой таблицы и это ручное редактирование / вставка, которые включают значение для столбца PK, возможно, Sheetal может пролить свет на это ...?)

Поэтому Sheetal должен изучить логику приложения, в области кода, который завершает вход в систему, после аутентификации пользователя, и искать экземпляры запросов, в которых указано значение для столбца UserLogId (отличного от условий WHERE). конечно).

Кстати, я не уверен почему мы все так стараемся? учитывая собственные минимальные усилия Шиталя по формулированию его вопросов, даже при рассмотрении возможной проблемы с английским языком и предоставлением информации. .. и , конечно, его скорость принятия ... ;-)

- следующее неверно (на основании неверной гипотезы) ----

Кажется, проблема в том, что UserLoginId объявлен в качестве первичного ключа для таблицы журнала. Это странный выбор для такой таблицы, потому что мы ожидаем, что для данного пользователя будет много записей журнала.

В таблице SQL ограничение первичного ключа, по сути, предписывает SQL отклонять любой запрос INSERT для записей со значением первичного ключа, которые легко существуют в таблице. (И вернуть условие ошибки, подобное тому, которое упоминалось в вопросе)

Трудно посоветовать не знать схему таблицы журнала и вариант использования, но вы можете вообще удалить ограничение pk или использовать для него другой столбец. Автоинкрементный столбец с именем «EventId» может быть хорошим выбором для этого. Вы получите что-то подобное в таблице журнала:

EventID (PK)   DateTime              UserLoginId  EventType     Details
1              01/02/2008 06:15:01   172          LogIn         Stan
2              01/02/2008 06:15:21   321          LogIn         Jeff
3              01/02/2008 06:15:24   172          FileDownload  Report7.pdf
4              01/02/2008 06:15:54   172          FileDownload  SalesTraining.pdf
5              01/02/2008 06:17:21   321          LogOut        

и т.д ...

Answer 2

Вы установили для своих столбцов идентичности автоинкремент. Это не похоже на проблему числового диапазона. Скорее всего, вы явно указываете значение первичного ключа при создании новой записи UserLog. Сообщение об ошибке заставляет меня поверить, что в таблице UserLog уже существует запись с тем же значением первичного ключа, которое вы пытаетесь добавить.