Мне тут понадобилось "автоинкрементное" поле в регистре сведений. Вот терь думаю как лучше сделать если представим одновременную попытку 10 сеансов записи очередного элемента, ведь может произойти случайность что например 2 из 10 запросом на максимум получат случайно одно и тоже число.

У меня пока есть идиотская идея : сделать фиктивную константу, и делать запись в регистр через менеджер константы (так как на скоко я помню если 10 сеансов захотят записать одну и ту же константу, то для доступа в модуль менеджера значения они выстраиваються в очередь не заходя в модуль, чего не скажешь если сделать блокировку - как я заметил все ждут уже после считывания и ввода данных на самом моменте записи).
Я могу ошибаться, так что кто чо думает?

(0)автонумерацию делаешь?

(1) Ну тип думаю как если дофига одновремееных конектов будет (такое конешь наврятли будет, ну мало ли)

(0) Можно конешь попробывать в модуле набора записей тож самое сделать, но тогда вычисление инкремента будет прямо в модуле набора записей, то есть наверно конфликты могут быть

блокировка и селект максимум

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

Не понял вопроса.
Что мешает устанавливать исключительную блокировку перед тем как делать запрос на максимум?

(6) ну хз в управляемом режиме пробывал на справочниках, но увидел что исключительная определяет ток то что если сеанс заранее заблокировал элемент справочника исключительной блокировкой, то он пока блокировку не снимет ни кому не даст сделать запись.

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

(7) Исключительная блокировка не должна ни кому дать не только записывать, но и читать...

(9) Попробуй сам, я этого чот не ощутил

(9) Исключительная не дает другим поставить другим вообще любую блокировку, а разделяемая ток исключительную не даст.
Не конеш можно ставить исключительную блокировку исключительную на весь регистр, ну всмысле каждый сеанс будет пытаться ставить исключительную перед записью, тогда да вродь все получается. Но эт значит в остальным сеансам с разделяемой блокировкой не вариант (хотя мож и нафик не надо))).

А так смотрите какая идея:
Сделали фиктивную константу булевую к примеру. Создаем Менеджер значения, пихаем данные регистра в ДополнительныеСвойства.
В самом модуле константы считываем максимальный инкремент и делаем запись.
То есть все новые записи делать через Константу, ну а изменения как получиться.
Хотя идея конеш велосипедная)))

Ладно я все понял, будем делать без велосипедов )))

(11) в данном случае нужна блокировка обновления. В управляемом режиме она соответствует исключительной. Если читаешь, то она не мешает; запись блокирует; но если соберёшься читать, а потом обновлять, то её надо самому поставить.

(2)ну уже тыщу раз обсуждали
используй справочник для номеров, да лишня таблитса, да пофик, зато никаких траблов

Какая же гадость эта ваша заливная рыба!

(0) Зачем устанавливать блокировку ??? Проверяй при записи есть ли уже такое поле, если есть - добавляй 1.

(17)пример: пусть в регистре последняя запись ххх
юзер А читает регистр, прибавляет единицу, начинает писать в рег ххх+1, транзакция еще не завершена (идет запись)
в это время юзер Б читает регистр, далее сам понимаешь

(18) Можно после записи проверять.

(19)если бы было так, люди бы ваапще не парились бы с блокировками

(19) Какой после записи если представим вариант (18) то у тя исключение вылетет при попытке записать (у наз же инкремент это измерение регистра)

(15) Да тож думал об этом, но бесят лишние реквизиты ненужные

Без справочника будет трудно обойтись.
Самый простой вариант - элемент справочника и его поле "Код".
Более сложный вариант - блокировка элемента, в котором в каком-то реквизите хранится номер - каждый сеанс, который меняет номер - обязан получить номер из этого элемента и увеличить его на единицу - конечно - сеансы будут друг друга блокировать, но зато вероятность наложения и взаимоблокировок маловероятна.

(22)вот почитай v8: 8.2 Как распараллелить работу пользователей

(24)+ >>Есть непериодический, независимый регистр сведений "Номера" с 1 измерением "Порядковый номер". Режим управления блокировкой "Управляемый"
Есть 30 пользователей, которые одновременно раз в секунду жмут кнопку, по которой в этот регистр должна добавиться запись с порядковым номером на 1 больше максимального.

Если использовать след. вариант, то 29 пользователей, получив один и тот же номер, ЖДУТ 20 СЕК. установку блокировки, пока 1 записывает максимальный номер.(цы)

Что если писать период записи, и потом регламентной обработкой  рассчитывать этот параметр раз в 5 секунд?

Если записи совпали вплоть до секунд, ничто нам не мешает сравнить по моменту времени регистратора (записи?) или другого измерения документа.