Ошибка "операция не может быть выполнена из-за несоответствия версии ..." #761286


#0 by Про100Филя
Возникает при записи когда у нескольких пользователей открыт один и тот же обьект и один из них уже изменил его. Где можно отловить в исключении эту ошибку для нескольких объектов? Возможно сделать это через подписку на событие?
#1 by vde69
зачем? что бы такого не было достаточно отказаться от программной записи в пользу интерактивных действий и проблемы не будет
#2 by lera01
Надо блокировать, чтобы, если кто-то первый открыл, у других или вообще не открывалось или только на просмотр.
#3 by vde69
ты не прав... там играют версии объекта... (это число которое увеличивается на 1)
#4 by aleks_default
при программной записи блокировка не работает.
#5 by mistеr
Какого результата хочешь добиться?
#6 by Про100Филя
Поймать ошибку на стороне клиента и вывести ему сообщение.
#7 by Armando
Читать про объектные блокировки
#8 by vde69
не надо ничего ловить а тем более на клиенте попробуй открываешь 2 сесии одной базы в обоих сессиях открываешь одного и того-же контрагента в первой базе редактируешь наименование и оставляешь форму висеть во второй базе пробуешь отредактировать наименование... потом отпишись как же тебе удалось получить 2 разных объекта...
#9 by mistеr
Похоже он хочет уйти от пессимистической блокировки.
#10 by vde69
он не знает, что это такое, иначе бы догадался, что например в веб клиенте на клиентской стороне вообще ни о каких блокировках не может идти речи в принципе... то есть он не продумывает все режимы работы а пытается найти заплатку которая сработает здесь и сейчас...
#11 by Про100Филя
- Прочитал, здорово, но ответа ненашел. - Мне не нужно получение двух объектов. Блокировка заблокированного объекта базы данных вызывает исключение, которое может быть обработано конструкцией Попытка ... Исключение ... КонецПопытки. Где лучше будет реализовать конструкцию для нескольких объектов конфигурации?
#12 by vde69
>>>Мне не нужно получение двух объектов. тогда тебе и блокировки не нужны, а нужны ВЕСИИ объектов для избежание коллизий (о чем я писал в 3) давай я распишу как получается ситуация 1. где-то я получаю объект версии 1 изменяю его до версии 2342 но еще не записываю 2. в другом месте я то же получаю объект версии один и изменяю его до версии 3234 и записываю 3. первый процесс хочет записать версию 2342 и видит, что в базе уже лежит версия 3242 (а должна была лежать версия 1) и выдает тебе сообщение.... то есть никаких блокировок нет.... опиши чего тебе надо? что бы если кто то открыл объект (для редактирования) то никто другой не смог записать его втихую? если да - то как это сделать я написал в
#13 by Cyberhawk
Делай команду обновления данных формы, (метод Прочитать у объекта или формы), чтобы избежать оптимистической блокировки
#14 by Fragster
в обработчик ожидания получение версии объекта по объект.ссылка. Если отличается от версии, что на клиенте, то раскрашиваем форму в красный, вплоть до нажатия на кнопку "перечитать"
#15 by Fragster
при этом нужно понимать, что на большом количесвтве клиентов это может ТОРМОЗИТЬ
#16 by vde69
не надо ничего делать, и самое главное не надо программным способом записывать... и у автора будет поведение которое ему нужно
#17 by Fragster
посмотрю на тебя, полностью отказавшегося от программной записи, в т.ч. при обмене или восстановлении последовательности
#18 by Cyberhawk
А, хочешь сказать, при интерактивной записи из формы объекта происходит обновленые данных? Сомневаюсь. Или ты что-то другое имеешь в виду под "не надо программным способом записывать"? Поясни пож-та.
#19 by vde69
у нас есть документ который от начала редактирования до записи висит минут 20 и в нем разносят всякую фигню в ручном режиме, делаю я делаю 15 минут и тут обмен бах и перезаписал его, а у меня форма окрасилась в красный цвет и не дает записать это документ на 500 строк...
#20 by vde69
при интерактивном редактировании ты не сможешь создать новую версию объекта в памяти если версия базы отличается от версии "формы", как это выглядит: когда ты открываешь форму на редактирование она открывается "на чтение", как только ты пытаешься изменить любое поле формы имеющее признак "изменяет данные" идет проверка к базе, сравнение версий и создание своей версии в памяти, при этом на объект устанавливается блокировка и никто другой не может в интераткивном режиме изменить ни один реквизит с признаком "изменяет данные". то есть открывать формы - пожалуйсто, но модифицировать объект не даст
#21 by vde69
то есть при интерактивном режиме программа не дает начать редактировать объект, что и нужно автору. А запись тут совсем не причем...
#22 by Fragster
и как ты собираешься это разруливать при твоем способе? где гарантия, что с обменом не должен прилететь "более правильный" документ, и то, что ты делал нафиг оказывается не нужно?
#23 by NcSteel
Если объект родился в базе А, то и редактироваться должен в базе А, либо уже вторично не прилетать.... Коллизии должны быть четко разрулены.
#24 by vde69
эта ситуация не имеет общего для всех решения, у себя я обмену запретил изменять такие документы. То есть я запретил программную запись уже созданого документа :)
#25 by Fragster
ну бред же
#26 by Про100Филя
Действия пользователей не важны. Абстрактная задача "При возникновении блокировки выводить пользователю сообщение, что надо нажать кнопочку обновить и все норм будет." Мне не нужно городить свой велосепед с блокировками и делать я это не собираюсь. Ничего делать с блокированными объектами я тоже собираюсь. Читайте вопрос внимательнее.
#27 by Fragster
при "покраснении" формы можно сделать XML сериализацию текущей версии, версии из базы и сравнивалку ;)
#28 by NcSteel
Это не бред, а одна из корректных практик крупных проектов. Когда пользователей менее 10, то тут можно все отдать на самотек. При крупных внедрениях все должно быть регламентировано.
#29 by Fragster
+ чтобы свои изменения при "перечитывании" merge'ть  тем, что сделал другой пользователь/что прилетело с обменом
#30 by NcSteel
Если пользователь может редактировать документ, которые может измениться через обмен, то это фейспалм. В обчной ситуации такого быть не должно.
#31 by vde69
в моем случае - не бред, хотя для других это бред... все зависит от множества параметров, например есть выгрузка из торговли в бухгалтерию, я считаю, правильным выгружатиь в бухию документ в непроведеном виде и запретить обмену изменять уже проведеные в бухии документы. То есть в торговле провели документ - он полетел в бухию, там от не проведен, бух зашел, проверил, если надо поменял (например контрагента)  и провел, после этого документ блочится от изменений обмена, если надо синхронзировать бух отменяет проведение в бухии и препроводит в торговле... тем самым я добиваюсь персональной ответственности за бухию и отделение торговли от тотальной проверки бухами...
#32 by Fragster
"обмен" - это один из случаев, когда 100% происходит программная запись. и да, на большом РИБ при отгрузке, например, с другого склада, даже при "онлайн" режиме с пробросом через вебсервисы в "базу-получатель" в базе-получателе этот документ может смотреть пользователь, а в другом узле в это время в этот документ (без статуса "к отгрузке") могут добивать позиции. ну, или устанавливать тот самый статус.
#33 by vde69
зачем из узла в цент выгружать непроведеный (а значит не полностью сформированный) документ? ну а когда он уже выгружен его можно и блокернуть от изменений на узле. Короче это все зависит от методики решения коллизий.
#34 by Cyberhawk
Ясно, спс за ликбез (давно-давно в толстой книге вроде читал такое)
Тэги: 1С 8
Ответить:
Комментарии доступны только авторизированным пользователям

Похожие вопросы 1С

В этой группе 1С