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

делаю в передзаписью()
Если ЭтотОбъект.ВерсияДанных < Ссылка.ПолучитьОбїект().ВерсияДанных Тогда
Отказ = ИСТИНА ВОзврат; КОнецЕсди;

косяк в том что иногда более свежая версия имеет строковое представление    меньшее чем версия на форме, если сравнивать их как строки.

то ли я чтото не так делаю, то ли алгоритм сравнения надо свой написать.
Может ктото сталкивался с таким?

Как ты определяешь "большую свежесть" у версий?

я открываю док и меняю в реквизит в форме и не записываю.
захожу в другой сеанс, меняю док и записываю.
в базе версия более свежая чем открыта в форме в первом сеансе,
но если посмотреть в первом сеансе через отладчик, то
ЭтотОбъект.ВерсияДанных будет к примеру ААоооооWt
а в базе будет версия ААооооо8q

и если сравнить их как строки, то получится что
"ААоооооWt">"ААооооо8q"=ИСТИНА

хотя на самом деле ААооооо8q - более свежая версия, но т.к. оно их нумерует как-то странно, то сравнение строк кривовато работает в итоге

У тебя словесный понос? Ответь на вроде бы простой вопрос

(1) эмпирически

И с чего ты тогда взял, что операция ">" должна прокатывать?

(5) я попробовал - похоже не прокатывает

Почему простое неравенство не подходит?

(7) неравенство покажет отличие, но не свежесть.

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

Заменить все цифры на
Символ(КодСимвола(Цифра)-КодСимвола("0")+1+КодСимвола("z"))

Чем, кстати, стандартный механизм не угодил?

(11) стандартный это какой?

(12) В типовых от 1С во втором сеансе не даст изменить документ, т.к. он заблокирован в первом сеансе.
Если даже удастся записать во втором сеансе, то при записи в первом не запишет, сообщит что-то типа "объект уже изменен... что-то там версия данных отличается..."
Вроде так.

(9) то есть оно все-таки действительно не по алфавиту и мне не показалось)

вмсето даты можно еще заюзать ТекущаяУниверсальнаяДатаВМиллисекундах()
тогда с точностью до миллисекунд будет

(13) люди не хотят нажимать две лишние кнопки. хотя чтобы при нажатии кнопки записать если объект был уже кем-то изменене, то тупо форма закрылось и все

(12) а в стандарте придется сначала ответить на вопрос "записать да\нет",  а потом еще нажать ОК на предупрждении что не удалось записать. а потом еще и форму закрыть вручную и нажать "нет" на вопрос "записать да\нет"

Автоматизируя хаос получаем автоматизированный хаос.

(15) Но они же не узнают, применятся их изменения или нет.

Записывай в попытке и анализируй исключение xd

(15) не давайте изменять объект если с ним уже кто-то работает.

(8) Правильно. Почему этого недостаточно?

(14) не сработает, если запишут в пределах одной миллисекунды

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

Автор, ты приготовил три конверта?

(15) Т.е. юзер поставил галку, нажал Ок, документ закрылся, ни о чем не сообщил, и галки в нем нет. Вот это номер. Я бы не стал так делать.

Кстати основной довод автора - "т.к. все равно сохранить не получится"(0) - ошибочен. Сохранить - не проблема. Сложнее определить какая версия достойна быть в базе сохраненной.

(24) А как сохранить, например, после получения сообщения об оптимистичной блокировке?

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

(26) религия не позволяет, видимо.

(25) Ранее я использовал ВерсииОбъектов, а сейчас наверное можно и РезультатыОбменаДанными задействовать.

*(28) Наверное, сложно сказал :) Форма списка РС "Предупреждения при синхронизации данных" более удобна для интерфейса с юзвером по показу возникших коллизий (после внесения незначительных изменений в конфигурацию).

зачем?

РИБ - при обмене он умеет выдергивать коврик из-под ног юзверей :(

(31) А как при РИБ понять, что текущая версия более/менее правильная, чем та, которая пришла по обмену? Надо распределять документы по разным базам

(28) (29) Хз о чем ты. Внесенные изменения после получения оптимистичного отлупа уже не получить никак.

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

(33) Хз о чем ты. См. http://catalog.mista.ru/public/543218/ последние две фразы.

у меня бюжэет на эту задачу 1000-2000 руб, поэтому мне попроще решение надо с минимумом изменений

попробую вариант из (10)

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

(36) задачи "спасать" не было

(34) а пользователи с этим разбираются вообще? может каждому нормально - в базе 1 работает пользователь 1 с его версией объекта. А в базе 2 - пользователь 2 с его версией объекта. Чего им по регистрам версий смотреть, время тратить

(38) РИБ, общие объекты мигрируют с обменом между узлами...  и в любой момент может всплыть факт одновременного (между сеансами обмена) изменения одного и того-же объекта в нескольких узлах. Погугли "коллизии, возникающие при обмене данными".
Сидит юзверь, открыв форму, редактирует объект, а в это время происходит сеанс обмена данными и... и может возникнуть тема этой ветки.

(2) А шо там в с8 уже убрали объектные блокировки?

в итоге решил забить, сказав что так нельзя сделать и от меня отстали