Возникает при записи когда у нескольких пользователей открыт один и тот же обьект и один из них уже изменил его. Где можно отловить в исключении эту ошибку для нескольких объектов? Возможно сделать это через подписку на событие?

зачем?

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

Надо блокировать, чтобы, если кто-то первый открыл, у других или вообще не открывалось или только на просмотр.

(2) ты не прав...

там играют версии объекта... (это число которое увеличивается на 1)

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

(0) Какого результата хочешь добиться?

(5)Поймать ошибку на стороне клиента и вывести ему сообщение.

Читать про объектные блокировки
http://its.1c.ru/db/metod8dev#content:5839:hdoc

(6) не надо ничего ловить а тем более на клиенте

попробуй

открываешь 2 сесии одной базы
в обоих сессиях открываешь одного и того-же контрагента
в первой базе редактируешь наименование и оставляешь форму висеть
во второй базе пробуешь отредактировать наименование...

потом отпишись как же тебе удалось получить 2 разных объекта...

(8) Похоже он хочет уйти от пессимистической блокировки.

(8) он не знает, что это такое, иначе бы догадался, что например в веб клиенте на клиентской стороне вообще ни о каких блокировках не может идти речи в принципе...

то есть он не продумывает все режимы работы а пытается найти заплатку которая сработает здесь и сейчас...

(7) - Прочитал, здорово, но ответа ненашел.
(8) - Мне не нужно получение двух объектов.
(9)(10) Блокировка заблокированного объекта базы данных вызывает исключение, которое может быть обработано конструкцией Попытка ... Исключение ... КонецПопытки.
Где лучше будет реализовать конструкцию для нескольких объектов конфигурации?

>>>Мне не нужно получение двух объектов.
тогда тебе и блокировки не нужны, а нужны ВЕСИИ объектов для избежание коллизий (о чем я писал в 3)

давай я распишу как получается ситуация (0)

1. где-то я получаю объект версии 1 изменяю его до версии 2342 но еще не записываю
2. в другом месте я то же получаю объект версии один и изменяю его до версии 3234 и записываю
3. первый процесс хочет записать версию 2342 и видит, что в базе уже лежит версия 3242 (а должна была лежать версия 1) и выдает тебе сообщение....


то есть никаких блокировок нет....

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

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

в обработчик ожидания получение версии объекта по объект.ссылка. Если отличается от версии, что на клиенте, то раскрашиваем форму в красный, вплоть до нажатия на кнопку "перечитать"

при этом нужно понимать, что на большом количесвтве клиентов это может ТОРМОЗИТЬ

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

(16) посмотрю на тебя, полностью отказавшегося от программной записи, в т.ч. при обмене или восстановлении последовательности

(16) А, хочешь сказать, при интерактивной записи из формы объекта происходит обновленые данных? Сомневаюсь. Или ты что-то другое имеешь в виду под "не надо программным способом записывать"? Поясни пож-та.

(17)

у нас есть документ который от начала редактирования до записи висит минут 20 и в нем разносят всякую фигню в ручном режиме, делаю я делаю 15 минут и тут обмен бах и перезаписал его, а у меня форма окрасилась в красный цвет и не дает записать это документ на 500 строк...

(18) при интерактивном редактировании ты не сможешь создать новую версию объекта в памяти если версия базы отличается от версии "формы", как это выглядит:

когда ты открываешь форму на редактирование она открывается "на чтение", как только ты пытаешься изменить любое поле формы имеющее признак "изменяет данные" идет проверка к базе, сравнение версий и создание своей версии в памяти, при этом на объект устанавливается блокировка и никто другой не может в интераткивном режиме изменить ни один реквизит с признаком "изменяет данные".

то есть открывать формы - пожалуйсто, но модифицировать объект не даст

(20) то есть при интерактивном режиме программа не дает начать редактировать объект, что и нужно автору. А запись тут совсем не причем...

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

(22) Если объект родился в базе А, то и редактироваться должен в базе А, либо уже вторично не прилетать.... Коллизии должны быть четко разрулены.

(22) эта ситуация не имеет общего для всех решения, у себя я обмену запретил изменять такие документы. То есть я запретил программную запись уже созданого документа :)

(24) ну бред же

(12) Действия пользователей не важны. Абстрактная задача "При возникновении блокировки выводить пользователю сообщение, что надо нажать кнопочку обновить и все норм будет."

Мне не нужно городить свой велосепед с блокировками и делать я это не собираюсь. Ничего делать с блокированными объектами я тоже собираюсь. Читайте вопрос внимательнее.

при "покраснении" формы можно сделать XML сериализацию текущей версии, версии из базы и сравнивалку ;)

(25) Это не бред, а одна из корректных практик крупных проектов.

Когда пользователей менее 10, то тут можно все отдать на самотек. При крупных внедрениях все должно быть регламентировано.

(27)+ чтобы свои изменения при "перечитывании" merge'ть  тем, что сделал другой пользователь/что прилетело с обменом

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

В обчной ситуации такого быть не должно.

(25) в моем случае - не бред, хотя для других это бред...

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

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

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

(30) "обмен" - это один из случаев, когда 100% происходит программная запись. и да, на большом РИБ при отгрузке, например, с другого склада, даже при "онлайн" режиме с пробросом через вебсервисы в "базу-получатель" в базе-получателе этот документ может смотреть пользователь, а в другом узле в это время в этот документ (без статуса "к отгрузке") могут добивать позиции. ну, или устанавливать тот самый статус.

(32) зачем из узла в цент выгружать непроведеный (а значит не полностью сформированный) документ?

ну а когда он уже выгружен его можно и блокернуть от изменений на узле.

Короче это все зависит от методики решения коллизий.

(20) Ясно, спс за ликбез (давно-давно в толстой книге вроде читал такое)