привет всем!
может кто подскажет как программно снять/установить свойство identity у столбца?

 

ALTER TABLE ?

Какой сервер баз данных ?

 

MS SQL SERVER 2000
я знаю, что это мона сделать в enterprise manager, но хотелось бы узнать как это делать с помощью SQL запроса
Почти наверняка это ALTER TABLE, но вот, что после этих 2 слов писать, я не знаю

 

MODIFY COLUMN?

 

SET IDENTITY_INSERT
http://msdn.microsoft.com/library/default....et-set_7zas.asp

 

Гммм.. как показало глубокое вскрытие ... такого сделать с помощью T-SQL нельзя... по крайней мере в MS SQL Server ...

Проанализировав то что делает Enterprise Manager выяснилось ...

1. Создаётся новая таблица где у поля IDENTITY есть или нет
2. Копируются данные из основной таблицы
3. Удаляется основная таблица
4. Переименовывается вновь созданная в таблицу с нужным именем


Так что ... только так Вам и надо делйствовать ...

Мда .. не ожидал что такая проблема так решается ...

 

Или как вариант создать новую колонку с нужным вам идентити, потом скопировать в ней данные от старой колонки и потом старую колонку удалить... но это вариант сродни перемещению всех данных в таблице ...

 

Спасибо огромное за такой развернутый ответ
тогда напрашивается другой вопрос: все это я хотел затеять только потому, что таблица моя будет достаточно интенсивно испытывать операции вставки/удаления, и как следствие, я хотел бы обезопасить себя от переполнения автоинкрементного столбца, делать я это собирался так: снять автоинкремент, сделать нечто вроде update table set column = column - 10000, установить автоинкремент. Может есть другое решение этой проблемы(переполнение)?

 

А как насчёт использовать ROWGUID ? Проблема переполнения не страшна

 

Все таки использование свойства identity позволяет отслеживать хронологию поступления сообщений, поэтому я написал пользовательскую функцию:
CREATE FUNCTION countJur
()
RETURNS int
AS
BEGIN
DECLARE @res int
SELECT @res = MAX(id)
FROM JUR

if( @res = NULL )
RETURN( 0 )
RETURN ( @res )
END
и использую ее следующим образом:
insert into JUR(id,type,_time,param) values (dbo.countJur()+1,@type,@_time,@param)
это позволяет создать иллюзию использования identity но не накладывает ограничений на необходимый update, хотя конечно интересно что более затратно: использование этой функции или же копирование значений столбца identity для update

 

Все таки использование свойства identity позволяет отслеживать хронологию поступления сообщений, поэтому я написал пользовательскую функцию:
CREATE FUNCTION countJur
()
RETURNS int
AS
BEGIN
DECLARE @res int
SELECT @res = MAX(id)
FROM JUR

if( @res = NULL )
RETURN( 0 )
RETURN ( @res )
END
и использую ее следующим образом:
insert into JUR(id,type,_time,param) values (dbo.countJur()+1,@type,@_time,@param)
это позволяет создать иллюзию использования identity но не накладывает ограничений на необходимый update, хотя конечно интересно что более затратно: использование этой функции или же копирование значений столбца identity для update

 

Есть еще одно решение данной проблемы: заводится таблица, которая хранит максимальный Id всех необходимых таблиц (для который нужно сымитировать свойство identity) Эта таблица имеет формат MaxId INT, TableName VARCHAR(...). Перед помещением новой записи в какую-либо таблицу, нужно вызвать функцию, которая сгенерирует значение столбца якобы имеющего свойство Identity. Функция принимает как параметр имя таблицы, по этому имени обращается в созданную таблицу, берет оттуда данные и модифицирует таблицу, после чего возвращает необходимое значение.

 

Если уж такое дело то кто мешает перед вставкой делать SELECT MAX от ключевого поля + 1 .. и дополнительной таблицы заводить не придётся ...

 

насчет предложения Barmutik, это я сначала и сделал, но предложение о дополнительной таблице представляется более правильным с точки зрения производительности, так как эта таблица небольшая и много места не займет, не займет много времени и поиск требуемого элемента, а вот выбор максимального либо будет требовать много времени, либо надо будет завести для этого поля индекс, тогда соответсвенно этот вариант потребует много памяти. Так что предложение о дополнительной таблице хоть и менее тривиально, по размышлении кажется более грамотным

 

Стоп... судя по всеу мы говорим о ключевом поле .. а для этого поля автоматом строится индекс.. так что поиск максимального значения будт выполняться прямом переходм .. что равнозначно нулевым временным затратам...

А вот Ваш вариант .. особенно при большом количестве таблиц наоборот проигрывает в производителености потому как искать приходится по строковому значению.. если конечно по нему не построен индекс ...