Вот что стоило разработчикам SQL позволить INSERT возвращать значения автоинкрементируемых полей после вставки? Лишнего геморойства было бы меньше. Пока что вижу три способа узнать значение автоикремента и не знаю какой самый правильный.
1) Так сейчас делаю. После вставки сразу SELECT Where по вставленным полям и получаю id записи. Минус: если найденных записей несколько — нет гарантии, что у вставленной записи максимальный номер. Параллельно могла произойти еще одна вставка и вообще у автоинкрементного поля кажется гарантируется только уникальность, но не возрастание. Впрочем, тут могу ошибаться. На практике однако часто это не существенно или не случается.
2) Использовать SCOPE_IDENTITY() Минус тот же. Нет гарантии, что никто не добавил запись.
3) Триггер на вставку в таблицу, который пишет id в отдельную таблицу. Можно запутаться
В принципе есть еще вариант. Отказаться от автоинкремента, но оставить ограничение на уникальность и самому присваивать id, если возникнет ошибка неуникальности, значит, кто-то параллельно добавил и надо просто продолжать добавлять записи с id++ пока не добавится.
Вот как корректнее всего даже и не знаю. А может я и вовсе чего-то не понял.
Здравствуйте, Michael7, Вы писали:
M>Вот что стоило разработчикам SQL позволить INSERT возвращать значения автоинкрементируемых полей после вставки? Лишнего геморойства было бы меньше. Пока что вижу три способа узнать значение автоикремента и не знаю какой самый правильный.
M>Вот как корректнее всего даже и не знаю. А может я и вовсе чего-то не понял.
Нужно получать значения произвольных автоикрементируемых полей? Или только PK поле с назначенным IDENTITY() ?
INSERT INTO ... (...)
OUTPUT INSERTED.IDENTITYCOL
VALUES (...)
Не пойдет ?
Re[2]: Правильные способы узнать id после INSERT в MS SQL 20
Здравствуйте, Lexey, Вы писали:
L>Здравствуйте, Michael7, Вы писали:
M>>2) Использовать SCOPE_IDENTITY() Минус тот же. Нет гарантии, что никто не добавил запись.
L>Хм... зачем тебе гарантия, что кто-то еще не добавил запись? Обычно нужен identity записи, добавленной твоим батчем. SCOPE_IDENTITY() его и вернет.
Я думал оно вообще вернет последний identity в базе.
Re: Правильные способы узнать id после INSERT в MS SQL 2012
Функции SCOPE_IDENTITY и @@IDENTITY возвращают последние значения идентификатора, созданные в таблицах во время текущего сеанса. Однако функция SCOPE_IDENTITY возвращает значения, вставленные только в рамках текущей области, тогда как действие функции @@IDENTITY не ограничивается никакими областями.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, DarkMaster, Вы писали:
DM>Здравствуйте, fplab, Вы писали:
F>>Что-то мне подсказывает, что тут есть засада, но что если после INSERT-а сразу же выполнить запрос
F>>
F>>SELECT MAX (id) FROM <table>
F>>
F>>?
DM>Представь для начала 100 пользователей, одновременно вставляющих данные в таблицу.
Я же и говорил — где-то тут засада
Приходиться заниматься гадостью — зарабатывать на жизнь честным трудом (Б.Шоу)
Re: Правильные способы узнать id после INSERT в MS SQL 2012
Здравствуйте, Michael7, Вы писали:
M>Вот что стоило разработчикам SQL позволить INSERT возвращать значения автоинкрементируемых полей после вставки? Лишнего геморойства было бы меньше. Пока что вижу три способа узнать значение автоикремента и не знаю какой самый правильный.
M>1) Так сейчас делаю. После вставки сразу SELECT Where по вставленным полям и получаю id записи. Минус: если найденных записей несколько — нет гарантии, что у вставленной записи максимальный номер. Параллельно могла произойти еще одна вставка и вообще у автоинкрементного поля кажется гарантируется только уникальность, но не возрастание. Впрочем, тут могу ошибаться. На практике однако часто это не существенно или не случается.
M>2) Использовать SCOPE_IDENTITY() Минус тот же. Нет гарантии, что никто не добавил запись.
M>3) Триггер на вставку в таблицу, который пишет id в отдельную таблицу. Можно запутаться
M>В принципе есть еще вариант. Отказаться от автоинкремента, но оставить ограничение на уникальность и самому присваивать id, если возникнет ошибка неуникальности, значит, кто-то параллельно добавил и надо просто продолжать добавлять записи с id++ пока не добавится.
M>Вот как корректнее всего даже и не знаю. А может я и вовсе чего-то не понял.
Все как раз наоборот. Свойство Identity гарантирует следующее:
• Each new value is generated based on the current seed & increment.
• Each new value for a particular transaction is different from other concurrent transactions on the table.
А вот уникальность оно не гарантирует. Вы можете самостоятельно изменить параметр Seed и начать использовать значения автоинкремента повторно, т.е. зациклив его.
Не гарантируется так же порядок вставки сгенерированных значений в таблицу, т.е. меньшее значение может быть вставлено позже большего. Чревато это высокой фрагментированностью индекса, если он у вас есть на этом поле, ну и наличием неправильных значений в случае использования подхода, который здесь уже неоднократно упоминался — select max(value) from dbo.Table1
через output inserted, особенно если у вас выполняется вставка нескольких записей. Кроме того, этот же вариант одно время рекомендовал Microsoft, после того как была обнаружена проблема возврата некорректных значений при использовании функций @@identity и scope_identity() в параллельных планах запроса версий 2005 и 2008 (You may receive incorrect values when using SCOPE_IDENTITY() and @@IDENTITY). C SP1 эта проблема уже ушла, поэтому вариант со scope_identity() так же рабочий, несмотря на ваши опасения.
Мы уже победили, просто это еще не так заметно...
