В практике работы с распределенными базами данных и регулярной синхронизацией (например, между 1С:Управление торговлей 10.3 и 1С:Бухгалтерия предприятия 3.0) системные администраторы и программисты иногда сталкиваются с «мистическим» поведением системы. Типичная ситуация: документ в базе-приемнике внезапно оказывается помеченным на удаление, хотя в базе-источнике он проведен и актуален. При этом попытка разобраться через Журнал регистрации (ЖР) или Историю изменений (версионирование) не дает результатов — записей просто нет.
Рассмотрим подробнее причины этого явления, проанализируем механизмы работы платформы и выясним, как найти «виноватого» в этой ситуации.
Основная причина, по которой многие привычные механизмы контроля (подписки на события, проверки в модулях объектов) «молчат» при синхронизации — это использование свойства ОбменДанными.Загрузка. Проанализируем, как это работает:
Важно помнить, что хотя записи Данные.Изменение обычно попадают в ЖР даже при ОбменДанными.Загрузка = Истина, отсутствие записи может свидетельствовать о том, что изменение произошло в рамках одной массивной транзакции, которая не была завершена корректно или была перехвачена специфическим программным кодом.
Многие пользователи полагаются на подсистему «Версионирование объектов» из состава БСП (Библиотека стандартных подсистем). Однако здесь кроется ловушка. Разберем ситуацию:
Если в настройках программы для конкретного типа документа (например, «Реализация товаров и услуг») установлено значение «Версионировать при проведении», то система будет вести себя следующим образом:
Проанализируем сценарий: документ сначала был снят с проведения (например, обработкой или обменом), а затем помечен на удаление. Если в настройках не стоит «Версионировать всегда», то в истории изменений вы увидите только момент снятия с проведения, а сам факт пометки удаления останется за кадром. Это часто создает иллюзию того, что документ «самоудалился» без регистрации события.
Выясним причину, связанную с логикой работы самой синхронизации. Оказывается, пометка на удаление может быть следствием изменения настроек обмена в базе-источнике (УТ 10.3).
Рассмотрим по шагам механизм «очистки» данных:
В результате в БП 3.0 документ получает команду на отмену проведения или пометку на удаление. Это происходит программно через COM-соединение под системной учетной записью, и если фильтры Журнала регистрации настроены слишком узко (например, только по Тонкому клиенту), вы не увидите этих событий.
Проанализируем ситуацию с технической точки зрения работы платформы «1С:Предприятие 8.3». При подключении через COM-соединение создается отдельный сеанс. В Журнале регистрации такие события могут иметь следующие особенности:
.lgd/SQLite) не успел сбросить запись на диск.Чтобы найти истинную причину «барабашки», рекомендуем выполнить следующие действия:
1. Расширенный поиск в Журнале регистрации. Посмотрите события не за конкретный момент, а за весь период синхронизации, убрав фильтр по пользователю и приложению. Ищите события Данные.Изменение для этого конкретного объекта по его GUID или ссылке.
2. Проверка истории регистраций в УТ. В базе 1С:Управление торговлей откройте монитор обмена данными или обработку «Регистрация изменений для обмена». Проверьте, не зарегистрирован ли данный документ к удалению. Если в таблице регистрации изменений стоит пометка «Удаление объекта», значит, команда пришла именно оттуда.
3. Временная смена режима версионирования. Для проблемных документов установим режим «Версионировать всегда». Это позволит увидеть даже те изменения, которые не сопровождаются проведением документа.
4. Использование платформенного версионирования. В особо сложных случаях можно включить низкоуровневое версионирование на уровне платформы (через настройки conf.cfg), которое фиксирует обращения к СУБД, однако это требует значительных ресурсов сервера.
Пример программной проверки состояния режима загрузки в подписках на события, который может помочь отловить момент изменения:
Процедура ПриЗаписиОбъекта(Источник, Отказ)
Если Источник.ОбменДанными.Загрузка Тогда
// Здесь можно добавить запись в отдельный лог или файл
// чтобы убедиться, что объект пришел через обмен
ЗаписьЖурналаРегистрации("ОбменДанными.Загрузка", УровеньЖурналаРегистрации.Предупреждение, , Источник, "Объект изменен через загрузку");
КонецЕсли;
КонецПроцедуры
Если документ помечается на удаление «без следов», это не магия, а следствие работы алгоритмов синхронизации при определенных настройках фильтрации данных. Смещение даты начала обмена — наиболее вероятный кандидат на роль причины в типовых конфигурациях. Всегда проверяйте настройки версионирования («При проведении» против «Всегда») и не забывайте, что записи в Журнале регистрации от COM-соединений требуют внимательного поиска без лишних фильтров по приложению.