Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Изменения типа поля  [new]
mqn
Member

Откуда: Краснодар
Сообщений: 76
Всех приветствую, подскажите как программно можно изменить тип поля, с счетчика на обычный, а потом обратно на счетчик (поле КодЗаказа).
Таблица к примеру из 3 полей:
[dbo].[Учёт заказов](
[КодЗаказа] [int] IDENTITY(1,1) NOT NULL,
[КодКлиента] [int] NULL,
[№счёта] [nvarchar](50) NULL)
15 апр 14, 15:25    [15885582]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
Кавказ-сила
Member

Откуда: Москва
Сообщений: 261
https://www.sql.ru/forum/127456/rekomendacii-po-oformleniu-soobshheniy-v-forume
Подумайте также над тем, чтобы описать решаемую Вами задачу целиком. Возможно, что тот способ решения, который Вы стремитесь воплотить в жизнь, не является наилучшим, а лишь кажется Вам таковым
15 апр 14, 15:30    [15885630]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
Glory
Member

Откуда:
Сообщений: 104751
mqn
как программно можно изменить тип поля, с счетчика на обычный, а потом обратно на счетчик (поле КодЗаказа).

Через создание новой таблицы с новым полем и переносом туда данных.
15 апр 14, 15:35    [15885674]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
Sergey Sizov
Member

Откуда:
Сообщений: 1579
mqn
подскажите как программно можно изменить тип поля, с счетчика на обычный, а потом обратно на счетчик (поле КодЗаказа).
[КодЗаказа] [int] IDENTITY(1,1) NOT NULL,
Для начала, это не счетчик.
15 апр 14, 15:39    [15885703]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
mqn
Member

Откуда: Краснодар
Сообщений: 76
Glory,

Мне не нужно создавать новую таблицу, она уже есть, мне необходимо перенести данные из одной таблицы в другую, с сохранением кода заказа, таблицы аналогичны по структуре. Но т.к поле типа счетчик запрос на вставку срабатывает, но данные не переносятся из-за этого поля. Вот я и собирался убрать счетчик, вставить и вернуть его назад.
Может существует более простой способ? Подскажите пожалуйста!
15 апр 14, 15:42    [15885733]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
HandKot
Member

Откуда: Sergiev Posad
Сообщений: 3058
mqn,
SET IDENTITY_INSERT (Transact-SQL)  
Позволяет вставлять явные значения в столбец идентификаторов таблицы
15 апр 14, 15:44    [15885753]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
Glory
Member

Откуда:
Сообщений: 104751
mqn
Мне не нужно создавать новую таблицу,

Тогда зачем вы спрашивате про " как программно можно изменить тип поля," ?
15 апр 14, 15:46    [15885762]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
Sergey Sizov
Member

Откуда:
Сообщений: 1579
mqn
Glory,

Мне не нужно создавать новую таблицу, она уже есть, мне необходимо перенести данные из одной таблицы в другую, с сохранением кода заказа, таблицы аналогичны по структуре. Но т.к поле типа счетчик запрос на вставку срабатывает, но данные не переносятся из-за этого поля. Вот я и собирался убрать счетчик, вставить и вернуть его назад.
Может существует более простой способ? Подскажите пожалуйста!
Вот с этого и надо было начинать. Почитать про Set identity_insert.
Заранее предупреждаю, в запросе на вставку надо будет явно прописать все поля.
15 апр 14, 15:46    [15885767]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
mqn
Member

Откуда: Краснодар
Сообщений: 76
Sergey Sizov,

На сколько я знаю, IDENTITY это свойство, которое необходимо для автоматического увлечения идентификатора. Но вопрос не в этом...
15 апр 14, 15:46    [15885770]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
mqn
Member

Откуда: Краснодар
Сообщений: 76
Спасибо за ответы, погуглю)
15 апр 14, 15:47    [15885775]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
Sergey Sizov
Member

Откуда:
Сообщений: 1579
mqn
Sergey Sizov,

На сколько я знаю, IDENTITY это свойство, которое необходимо для автоматического увлечения идентификатора. Но вопрос не в этом...
Ошибаетесь. Автоматического ИЗМЕНЕНИЯ и достижения тем самым уникальности. Еще раз - это не счетчик.
15 апр 14, 15:48    [15885788]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
iap
Member

Откуда: Москва
Сообщений: 47145
Sergey Sizov
mqn
Sergey Sizov,

На сколько я знаю, IDENTITY это свойство, которое необходимо для автоматического увлечения идентификатора. Но вопрос не в этом...
Ошибаетесь. Автоматического ИЗМЕНЕНИЯ и достижения тем самым уникальности. Еще раз - это не счетчик.
А как "тем самым достигается уникальность"?

Вот, к примеру, вставит сейчас mqn записи с явным [КодЗаказа],
а окажется, что такое значение там уже есть. Не получится, да?
15 апр 14, 15:53    [15885817]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
Sergey Sizov
Member

Откуда:
Сообщений: 1579
iap
Sergey Sizov
пропущено...
Ошибаетесь. Автоматического ИЗМЕНЕНИЯ и достижения тем самым уникальности. Еще раз - это не счетчик.
А как "тем самым достигается уникальность"?

Вот, к примеру, вставит сейчас mqn записи с явным [КодЗаказа],
а окажется, что такое значение там уже есть. Не получится, да?
Ну так ВСТАВИТ, а не АВТОМАТИЧЕСКИ УВЕЛИЧИТСЯ. Разница понятна?
15 апр 14, 15:57    [15885848]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
iap
Member

Откуда: Москва
Сообщений: 47145
Sergey Sizov
iap
пропущено...
А как "тем самым достигается уникальность"?

Вот, к примеру, вставит сейчас mqn записи с явным [КодЗаказа],
а окажется, что такое значение там уже есть. Не получится, да?
Ну так ВСТАВИТ, а не АВТОМАТИЧЕСКИ УВЕЛИЧИТСЯ. Разница понятна?
Если автоматически увеличится,
а это значение в таблице уже есть,
то увеличения не произойдёт?
Или уникальность нарушится?
15 апр 14, 15:59    [15885863]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
Sergey Sizov
Member

Откуда:
Сообщений: 1579
iap
Sergey Sizov
пропущено...
Ну так ВСТАВИТ, а не АВТОМАТИЧЕСКИ УВЕЛИЧИТСЯ. Разница понятна?
Если автоматически увеличится,
а это значение в таблице уже есть,
то увеличения не произойдёт?
Или уникальность нарушится?
Речь о постороннем грубом вмешательстве в процесс. Так понятнее?
15 апр 14, 16:01    [15885881]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
iap
Member

Откуда: Москва
Сообщений: 47145
Sergey Sizov
iap
пропущено...
Если автоматически увеличится,
а это значение в таблице уже есть,
то увеличения не произойдёт?
Или уникальность нарушится?
Речь о постороннем грубом вмешательстве в процесс. Так понятнее?
Таким образом, утверждение об уникальности поля, у которого есть лишь свойство IDENTITY, - ЛОЖНО.
Можно так сказать?
Человек, упорно не признающий ошибочность своего утверждения, выглядит как-то не очень....
15 апр 14, 16:05    [15885911]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
Sergey Sizov
Member

Откуда:
Сообщений: 1579
Модератор: Я случайно вместо "цитата" нажал "изменить" и затер пост. Sergey Sizov, если не сложно, напишите его еще раз. ГСА


Сообщение было отредактировано: 15 апр 14, 16:13
15 апр 14, 16:08    [15885932]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Sergey Sizov
iap
пропущено...
Если автоматически увеличится,
а это значение в таблице уже есть,
то увеличения не произойдёт?
Или уникальность нарушится?
Речь о постороннем грубом вмешательстве в процесс. Так понятнее?
Попробуйте для разнообразия хоть как-то вмешаться в процесс поддержания уникальности поля констрейтом (без DUP_KEY) и сделать в нем дубли.
15 апр 14, 16:09    [15885940]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
Sergey Sizov
Member

Откуда:
Сообщений: 1579
Гавриленко Сергей Алексеевич
Попробуйте для разнообразия хоть как-то вмешаться в процесс поддержания уникальности поля констрейтом (без DUP_KEY) и сделать в нем дубли.
Зачем? Что доказать-то уже вдвоем хотите? Может мое утверждение, на которые вы с iap так ополчились, внимательнее прочитать? Без подстановки туда смысла, который туда не вкладывали?
15 апр 14, 16:12    [15885963]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Sergey Sizov
Гавриленко Сергей Алексеевич
Попробуйте для разнообразия хоть как-то вмешаться в процесс поддержания уникальности поля констрейтом (без DUP_KEY) и сделать в нем дубли.
Зачем? Что доказать-то уже вдвоем хотите? Может мое утверждение, на которые вы с iap так ополчились, внимательнее прочитать? Без подстановки туда смысла, который туда не вкладывали?
Тогда не надо писать двусмысленных фраз типа "Автоматического ИЗМЕНЕНИЯ и достижения тем самым уникальности.". Identity просто тупой счетчик без всяких претензий на какое-то там достижение уникальности. Просто это побочный эффект, который можно довольно просто сломать.
15 апр 14, 16:16    [15885994]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
Sergey Sizov
Member

Откуда:
Сообщений: 1579
Гавриленко Сергей Алексеевич
Sergey Sizov
пропущено...
Зачем? Что доказать-то уже вдвоем хотите? Может мое утверждение, на которые вы с iap так ополчились, внимательнее прочитать? Без подстановки туда смысла, который туда не вкладывали?
Тогда не надо писать двусмысленных фраз типа "Автоматического ИЗМЕНЕНИЯ и достижения тем самым уникальности.".
Для туго думающих добавлю - "при соблюдении ряда условий и невмешательства в этот процесс".
Identity просто тупой счетчик без всяких претензий на какое-то там достижение уникальности. Просто это побочный эффект, который можно довольно просто сломать.
О чем и спич. Только это таки опять не счетчик, а автоинкремент. Начинать изменять вставляемое в это поле значение он может не только с единицы, не так ли?
15 апр 14, 16:20    [15886032]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Sergey Sizov
Для туго думающих добавлю - "при соблюдении ряда условий и невмешательства в этот процесс".
Если у вас такой "нетугой" ум, то вы могли бы и сами догадаться, что вас могут неправильно понять, особенно те, кто не очень в теме, например автор топика, который теперь, может быть, будет считать, что свойства identity для уникальности достаточно.
15 апр 14, 16:27    [15886078]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
Sergey Sizov
Member

Откуда:
Сообщений: 1579
Гавриленко Сергей Алексеевич
Sergey Sizov
Для туго думающих добавлю - "при соблюдении ряда условий и невмешательства в этот процесс".
Если у вас такой "нетугой" ум, то вы могли бы и сами догадаться, что вас могут неправильно понять,
Неправильно понять могут вне какой-либо зависимости от тугости ума.
особенно те, кто не очень в теме, например автор топика, который теперь, может быть, будет считать, что свойства identity для уникальности достаточно.
Он и так уже это поле посчитал счетчиком...
15 апр 14, 16:49    [15886236]     Ответить | Цитировать Сообщить модератору
 Re: Изменения типа поля  [new]
o-o
Guest
предлагаю завершить топик цитированием Kalen Delaney.
тут все: и про "уникальность", и про "дыры", и когда стОит использовать IDENTITY, и когда нет.
а относящееся к теме выделю, а то много получилось

The value automatically produced with the IDENTITY property is normally unique, but that
isn’t guaranteed by the IDENTITY property itself, nor are the IDENTITY values guaranteed
to be consecutive
. (I will expand on the issues of nonunique and nonconsecutive IDENTITY
values later in this section.) For efficiency, a value is considered used as soon as it is presented
to a client doing an INSERT operation. If that client doesn’t ultimately commit the INSERT, the
value never appears, so a break occurs in the consecutive numbers. An unacceptable level of
serialization would exist if the next number couldn’t be parceled out until the previous one
was actually committed or rolled back. (And even then, as soon as a row was deleted, the
values would no longer be consecutive. Gaps are inevitable.)

Note If you need exact sequential values without gaps, IDENTITY isn’t the appropriate feature
to use. Instead, you should implement a next_number-type table in which you can make the
operation of bumping the number contained within it part of the larger transaction (and
incur the serialization of queuing for this value).

To temporarily disable the automatic generation of values in an identity column, you use
the SET IDENTITY_INSERT tablename ON option. In addition to filling in gaps in the identity
sequence, this option is useful for tasks such as bulk-loading data in which the previous values
already exist. For example, perhaps you’re loading a new database with customer data from
your previous system. You might want to preserve the previous customer numbers but have
new ones automatically assigned using IDENTITY. The SET option was created exactly for cases
like this.

Because the SET option allows you to determine your own values for an IDENTITY column,
the IDENTITY property alone doesn’t enforce uniqueness of a value within the table.

Although IDENTITY generates a unique number if IDENTITY_INSERT has never been enabled,
the uniqueness is not guaranteed once you have used the SET option. To enforce uniqueness
(which you’ll almost always want to do when using IDENTITY), you should also declare a
UNIQUE or PRIMARY KEY constraint on the column.
If you insert your own values for an
identity column (using SET IDENTITY_INSERT), when automatic generation resumes, the next
value is the next incremented value (or decremented value) of the highest value that exists in
the table, whether it was generated previously or explicitly inserted.
15 апр 14, 17:51    [15886739]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить