Кто подскажет как происходит одновременное создание двух документов на уровне СУБД MS SQL. Могут ли быть блокировки если эти документы полностью различны кроме даты и номера. ПО идее при одновременном создании должен быть один номер, одна дата и одна и та же ссылка у записей в БД

(0)Как не прыгай - они не одновременно создаются в БД.

Читал на форумах, где Радченко писал, что создаются одновременно

(0) проблема то в чем?

(2) в компьютерах нужно очень постараться чтобы что нибудь случилось одновременно

>ПО идее при одновременном создании должен быть один номер, одна дата и одна и та же ссылка у записей в БД

по твоей идее?

хватит употреблять

тип отведенный под дату позволяет запихнуть в одну секунду больше одного документа

и пока один записывается второй ждет - блокировки работают

Есть REST клиент, который создает в 1С заказы, REST запросы могут выполняться параллельно. Случилась ситуация, когда REST клиент отправил два одинаковых запроса на создание заказа. По сути в 1С должны параллельно создаться два одинаковых заказа. В процессе создания заказа есть проверка по определенному ID, чтобы не было дублей. Получилось так, что создались два одинаковых заказа с одинаковым ID. Если бы один заказ создался бы раньше другого, то проверка бы выдала, что по такому ID уже есть заказ и второй не создался бы.

(0) Что в твоём понимании значит "при одновременном"?
Генерацию уникальных номеров и кодов объектов обеспечивает сервис нумерации кластера серверов 1С. Этот сервис един для одной информационной базы. И даже пр переносе (миграции) сервиса между рабочими серверами кластера потери данных не происходит. То есть сервис продолжает обеспечивать уникальность кодов и номеров создаваемых объектов.

(2) фигню написал. SQL никак 2 одновременно записи в таблицу не напишет. Так что нет. Одновременно не создаются документы.

(9) это норма. первый спросил есть документ? и второй спросил есть ли документ. его не было, дальше создаются дубли

(9) >> ...есть проверка по определенному ID, чтобы не было дублей
>> ...создались два одинаковых заказа с одинаковым ID

Обратитесь к *опоруким программистам - авторам алгоритма проверки. Уточните у них по какой причине не были наложены исключительные блокировки по этому полю до начала проверки и вплоть до завершения транзакции записи объекта в БД.

(12) Так если в SQL не происходит одновременного создания записей, то документ должен был быть в БД

ну не слышал он о блокировках...

(9) Это совсем другая тема. Создался и записался - разное. И на уровне SQL одно, на уровне 1С - другое. Когда 1С создает документ, то SQL пока еще ничего не делает, сервер 1С выдает номер только (но не SQL). А вот при записи да. Притом вопрос проводится документ или нет. Если проводится и во время проведения проверяется это ID, то да, странно т.к. там все транзакции все. А если только запись - то смотря как и что написано. Но как вопрос в теме - нет, одновременно SQL не создает 2 документа. Более того, на 1 то документ SQL делает далеко не 1 запись.

(13)картина репина  "*опоголовый обращается к *опоруким"

(13) А причем тут исключительные блокировки? Документов еще нет в базе

(18) затем... откройте мурзилку по совместимости уровней блокировок

(14) Запись в 1С и запись в SQL - это ваще разное.

(14) для этого запрос на поиск и создание надо завернуть в одну транзакцию

чтобы второй ждал

(21) Алгоритм HTTP сервиса парсинга REST запроса, поиска заказа по ID, создание нового происходит в транзакции

(22) Ну а поиск тоже в транзакции?

(22) Вся очередь обработки запросов рест в одной транзакции, а не параллельная обработка разных запросов где каждый в своей транзакции

Оказывается транзакции нет, только что посмотрел

(24)+ Ну или делай резервирование номерков если параллельно хочешь

(26) зачем? достаточно транзакционно номер запрашивать. правда, возможно дырки будуит

если без блокировок, то 2 транзакция не увидит 1 ибо только read_commited.
Это если у тебя ID - это просто реквизит

(25) транзакция при записи всегда есть

а кто-нибудь смотрел, как это работает? https://i.imgur.com/ikWtyMi.png что-то в мануалах не нашел....

в смысле из справки ничего не понятно, когда это работает?

(30) Это с какого релиза?

я хз, 8.3.6 есть

Так как все - таки решить проблему то?

Обернуть все в транзакцию?

>если без блокировок, то 2 транзакция не увидит 1 ибо только read_commited.

в зависимости от 1с и базы может быть вообще read_commited_snapshot - вообще блокировок на чтение не будет

(36) Мы используем read_commited_snapshot

(36) блокировок нет, но и не увидит