Изначально задача бредовая, ибо клиент PK int генерить в принципе не имеет права (догадайтесь, почему). Если устроит накладывать лок на таблицу - вперёд на амбразуру.

А за такое


расстреливать на месте нужно.

НахлобучКлиент в принципе имеет полное право генерировать PK
Клиент в принципе не имеет полное право генерировать PK. Исключение составляет гуид, который обеспечивает должную уникальность.
Нахлобуч SCOPE_IDENTITY сломан .
Причём тут SCOPE_IDENTITY и генерация PK средствами SQL сервера?

НахлобучПро HiLo прочитал уже?
Изучили уже трассу SQL кода, которую он генерит?
НахлобучНу кагбэ если тебе SQL Server сгенерирует PK с помощью наиболее широко используемого автоинкремента (Identity), а ты его не сможешь правильно получить -- догадываешься, что потом получится?
Юзать output inserted

НахлобучСлив?
Куда?
НахлобучКакую трассу, о чем речь вообще?
О трассировке. Дать определение, что-ли?
НахлобучЯ задал вопрос, на который можно ответить либо "да", либо "нет".
Нет.
НахлобучС тебя патч для EF, который это будет делать.
Срочно в EF читать про SP Mapping Insert Function.

Нахлобучпосле чего на клиенте можно безопасно сгенерировать 10/100/1000/10000 уникальных идентификаторов. Чем это тебя так возбудило?
Сгенерили. Конкуренты тоже сгенерили. Дальше что?

Это чё за фигня? Каким образом другое приложение должно узнать о number of digits for LOW ? Само догадаться?
Во-вторых, это не гарантирует вставку такого же значения другим приложением.

Нахлобуч
И еще. Сами-то пробовали репродюсировать сломанность скоупидентити? Отвечать: да или нет.

НахлобучПрочитает из базы данных.
Атец, срочно читать организацию ACID, конекретно про Isolation (изолированность). Любое обновление определенной транзакции будет скрыто от остальных до тех пор, пока эта транзакция не будет зафиксирована . Выход из сложившейся ситуации - блокировка. Ресурс должен быть успешно захвачен для изоляции. А теперь включите моск и подумайте, надежен ли предлагаемый лисапет клиентских айди? Ответ - нет и только нет.
Тем более гавноHiLo не лочит ресурс, следовательно, надежность такой конструкции - ноль. До сих пор не втумкали, о чём я вещаю?
НахлобучНу ты по ссылке-то сходил или как? Гарантирует.
Читать долго и упорно про изоляцию. Так же не забыть подкрепить знания про атомарности батча.
НахлобучНа предыдущем месте работы сами столкнулись с таким.
Сказочник Вы однако. Весь мир юзает скоуп идентити и тут появляетесь Вы и рвете правду матку. Слабо еще разок спровоцировать описанное?

Нахлобуч
Специально по заявкам на пальцах: пример блокировки записи



Обратить внимание на закоментаренный COMMIT. Итак, что это значит? Это значит, что инструкции не могут считывать данные, которые были изменены (если выполняются манипуляции, как у меня в примере UPDATE), но еще не зафиксированы другими транзакциями (как-раз таки закоменченный COMMIT), а также на то, что другие транзакции не могут изменять данные, читаемые текущей транзакцией, до ее завершения .
Но! Другие транзакции могут вставлять новые строки, соответствующие условиям поиска инструкций, содержащихся в текущей транзакции. При повторном запуске инструкции текущей транзакцией будут извлечены новые строки, что приведет к считыванию фантома. В данном случае действуем по ситуации: либо меняем логику либо выбираем другой уровень изоляции.

P.S. Атец, поэтому я в начале и спросил про:

МСУИзучили уже трассу SQL кода, которую он генерит?

... на что увидел одни недоумения и ужас от таких слов.

и после этого, Вы, наконец, родили:

НахлобучМСУО трассировке. Дать определение, что-ли?Мда. Он генерирует ровно два стейтмента, после чего на клиенте можно безопасно сгенерировать 10/100/1000/10000 уникальных идентификаторов. Чем это тебя так возбудило?

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

P.S2. В закреплении материала: клиент может генерить уникальные идентификаторы? (гуидов не касается)
P.S3. По поводу гуидов. Никто не запрещает отправить с клиента гуид уже существующий в таблице. Следовательно, невозможность вставки и прочие ошибки. Это так, к размышлению.
P.S4. Генерацией уникального идентификатора должен заниматься сервер и только он (ну можно еще сделать искючение для uniqueidentifier полей, ладно)

Я, конечно, догадываюсь, что автор может хотеть организацию непрерывной последовательности (возможно даже с пересчётом). Это типа как генерация номера счет-фактуры (без пересчета, конечно) и иже. Но, это решается не "PK int не idenity (с)", а отдельным полем. И никакие хило и прочий ширпотреб тут не нужен. Алгоритмы не раз обсуждались на форуме MS SQL - поиск.

Нахлобуч
Я, видимо, в пустую тут трезвонил про атомарности, про изоляцию. Не вижу тут изоляцию батча записи сгенеренного ID.
Никак не допрёте, что транзакция должна закрывать уже после вставки, а не после получения ID.

Во-вторых. Вы издеваетесь? У меня миллион клиентов, теперь прикиньте, какие разрывы в int'e у меня будут? Тут даже bigint не спасет.
Никогда не встречались с переполнением инта? У меня один раз на биллинговом проекте было такое. Это пипец просто.

P.S. Еще раз: поюзайте форум MS SQL, там пробегали интересные алгоритмы реализации последовательностей.

НахлобучРасскажи, что тут мне изолировать, если у каждого клиента уникальный hi, на основе которого он генерирует уникальные в пределах всей БД идентификаторы? Если у меня hi == 12 и lo = 1000, то идентификаторы [12000, 12999] -- точно уникальные, таких уже никто не получит.
Изолировать нужно то, что попытается стиснуться мимо логики identity_info.

НахлобучДа на вставку можешь её хоть не открывать -- все равно конфликтов идентификаторов не будет.
Выше смотреть.

НахлобучНу давай считать.
Да, сейчас посчитаем. Считаете-то неправильно: клиент захватил себе 1000 значений. Использовал только одно значение и отвалился. Пришел другой клиент и захватил себе еще 1000 значений, заюзал только одно и отвалился. Смекаете, о чём я?
По правильному: нужно привязать диапазон значений к клиентую Тогда bigint вполне устроит. Но я не вижу в хиберовой реализации привязки диапазона значений к клиенту. Ясно, а чём трактую или опять разжевать?