Здравствуйте!

На форме выводится ТаблицаЗначений, заполненная некоторыми реквизитами контрагентов.
Пользователь может отредактировать значения любых полей в этой таблице.
При нажатии на кнопку "Записать" новые значения реквизитов надо записать в базу.

Но как убедиться, что в течение работы пользователя с этой таблицей, и на момент записи, контрагенты не были изменены в базе?
Есть какие-нибудь встроенные механизмы платформы, чтобы проверить это?

Как правильно надо сделать в данном случае?

Перед записью проверяй значения всех изменяемых реквизитов и отменяй запись, если нет измененных реквизитов

Хранить в вашей таблице версию данных

Вроде как в 1С есть оптимистическая блокировка объектов.
На как я понимаю, она работает только когда открывается "карточка" объекта (то есть например элемент справочника).

В моем случае объект не открывается. Просто ТЗ заполняется данными объектов.

(3)
0. прочтите в вашу таблицу вместе с данными версию объекта
в момент записи
1. заблокируйте объект
2. прочтите текущую версию объекта в бд
3. сравните с имеющейся на равенство - примите решение

(1) >> Перед записью проверяй значения всех изменяемых реквизитов и отменяй запись, если нет измененных реквизитов

А что значит "проверяй значения всех изменяемых реквизитов"?
В таблице пользователь ввел новые значения. Значит, где-то надо сохранить еще и старые значения?

(4) >> 0. прочтите в вашу таблицу вместе с данными версию объекта

А как это делается?

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

(7) Понял, спасибо, буду разбираться.

А если бы не было поля "ВерсияДанных", то пришлось бы тупо сравнивать старые значения реквизитов и текущие значения в БД. Верно?

Кстати, я тут подумал...
"ВерсияДанных" скорее всего обновляется даже просто при записи объекта, даже если данные у него не менялись. Ну например, пользователь просто открыл контрагента, и нажал кнопку "Записать и закрыть", и ВерсияДанных поменяется.
То есть "ВерсияДанных" говорит о том, что объект записан, но при этом не обязательно, что данные объекта изменились.
Правильно я понимаю?

(0) Заблокироватьданныедляредактирования , не?

(9) Ну допустим в ТЗ заполнены ведения 100 контрагентов.
Пользователь может смотреть на эту таблицу пару часов.
Держать два часа заблокированными 100 элементов справочника - нехорошо.

Вот нашел похожую тему:
ВерсияДанных

(0) ну узнаешь ты, что у половины контрагентов реквизиты изменены и что будет дальше ?

+(12) Поддерживаю.

Имея (10) сразу вопрос: Пользователь пару часов, а то и весь рабочий день ковыряет эту таблицу (изменяет реквизиты контрагентов на нужные) и вот, в конце рабочего дня, он весь вспотевший от напряжения и усталости жмет заветную кнопку "Внести изменения в базу данных".

Происходит проверка на то были ли изменены контрагенты в базе и, вуаля, 80 контрагентов были изменены в базе!

Зачем сотрудник весь день работал, куда теперь денем результаты его труда по актуализации реквизитов контрагентов?

Вывод - что-то тут не так в подходе к реализации задачи.

(12),(13) Интересное замечание.

По крайней мере это предотвратит порчу данных.
А также пользователь поймет, что не надо долго "спать". И будет вносить изменения небольшими порциями. Например, по 5 контрагентов.

(14) огласите накуа все это?

(14) 100% бред

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

Полагаю там сидит "бабушка" и говорит: я вашего 1с не знаю и знать не хочу, всегда вносила данные в экселе - сделайте мне так же в этом вашем 1с

(9) это пессимистическая блокировка никак не заблокирует от программной модификации объекта. Рабочий метод наверно только с ВерсияДанных ну а если "загоняться" детально по реквивизитам тогда смотреть в сторону Версионирования.

(0) Вроде в БСП идет просто перебор реквизитов по методанным и сравниваются с БД.
В типовом механизме регистрации в плане обмена.