← На главную

Ситуация, когда после планового обновления конфигурации (например, 1С:УСО или 1С:УПП) внезапно исчезает самописный документ, существовавший в базе годами, является критической. Особенно остро проблема встает, если сбой заметили не сразу, а спустя неделю, когда пользователи уже ввели большой объем новых данных в другие разделы системы. Просто откатить базу к бэкапу в этом случае нельзя — это приведет к потере недельной работы всей компании.

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

Анализ причин исчезновения объекта и ошибок SDBL

Разберем, почему документ мог пропасть. В системе 1С:Предприятие 8 метаданные хранятся в специальных системных таблицах (Config, DBSchema). Ошибка SDBL поле ID имеет тип REF SELF или ROWVersion обычно свидетельствует о серьезной рассинхронизации между логической структурой конфигурации и физическими таблицами в SQL-базе.

Рассмотрим основные причины такого сбоя:

1. Некорректное динамическое обновление: Если до основного обновления часто использовалось «демоническое» обновление (обновление конфигурации базы данных без выгона пользователей), в кэше метаданных могли накопиться ошибки. При попытке реструктуризации во время перехода на новый релиз (например, со 113 на 114) платформа могла исключить «проблемный» объект из новой схемы данных.
2. Сбой транзакции при обновлении: Если в процессе применения конфигурации произошел разрыв соединения с SQL-сервером или нехватка места в логах транзакций, таблицы документа могли остаться в SQL, но исчезнуть из описания DBSchema.
3. Человеческий фактор при объединении: Если обновление выполнялось через сравнение и объединение конфигураций (.cf или .cfu), исполнитель мог случайно снять галочку с самописного объекта, что привело к его удалению из метаданных при сохранении.

Проанализируем сопутствующие ошибки. Сообщение неверная ссылка на владельца в справочнике БанковскиеСчета указывает на то, что реструктуризация затронула не только пропавший документ, но и базовые справочники (Контрагенты или Организации), нарушив целостность ссылочных связей.

Шаг 1: Восстановление структуры метаданных

Прежде чем пытаться загрузить данные из бэкапа, мы должны вернуть сам объект «Документ» в дерево конфигурации. Без наличия метаданных любая обработка загрузки данных просто не поймет, куда записывать информацию.

Выполним следующие действия:

1. Создадим копию текущей («битой») рабочей базы. Все эксперименты проводим только на ней!
2. Развернем последний живой бэкап (где документ еще был на месте) в отдельную временную базу.
3. В конфигураторе рабочей базы выберем пункт меню Конфигурация — Сравнить, объединить с конфигурацией из файла. В качестве файла выберем .cf, выгруженный из бэкапа.
4. В открывшемся окне сравнения снимем все галочки. Найдем наш пропавший документ в дереве метаданных и отметим только его.
5. Нажмем Выполнить. После этого необходимо обновить конфигурацию базы данных (F7).

Важный момент: Если после добавления документа платформа при попытке обновления конфигурации БД выдает ошибку SDBL, это означает, что физические таблицы в SQL конфликтуют с новыми метаданными. В этом случае может потребоваться сначала удалить «зависшие» таблицы документа в SQL Management Studio (только если вы уверены, что будете восстанавливать данные из бэкапа через XML).

Шаг 2: Перенос данных с помощью обработки «Выгрузка и загрузка данных XML»

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

Рассмотрим использование типовой обработки с ИТС — ВыгрузкаЗагрузкаДанныхXML.epf. Этот инструмент позволяет переносить объекты «как есть», сохраняя их уникальные идентификаторы (UUID) и записи в регистрах.

Пошаговый алгоритм работы:

1. Откроем обработку в базе-бэкапе.
2. В списке объектов выберем наш документ (например, РаспределениеТЗР).
3. Установим период (если нужно) или настроим отбор по конкретным документам.
4. Критически важная настройка: На вкладке настроек выгрузки установим флаг «Выгружать с документами все его движения». Это позволит перенести записи из регистров накопления и бухгалтерии, даже если сам документ в новой базе не будет автоматически делать те же движения при проведении.
5. Нажмем Выгрузить и сохраним сформированный XML-файл.
6. Откроем эту же обработку в рабочей базе на вкладке Загрузка и выберем наш файл.

Проанализируем результат. После загрузки документы появятся в списке. Проверьте их движения через кнопку «Результат проведения». Если флаг выгрузки движений был установлен, вы увидите все 15 регистров (партионные, бухгалтерские и т.д.) заполненными данными из бэкапа.

Шаг 3: Исправление ошибок ссылочной целостности

Если после восстановления документов Тестирование и Исправление (ТиИС) продолжает выдавать ошибки типа неверная ссылка на владельца для банковских счетов, воспользуемся обработкой «Универсальные подбор и обработка объектов».

Рассмотрим, как исправить «битые» ссылки на владельцев:

1. В обработке выберем объект СправочникСсылка.БанковскиеСчета.
2. Настроим отбор: Владелец — Не заполнено (или укажем конкретные счета, на которые ругался ТиИС).
3. В методах обработки выберем «Установить реквизит».
4. Укажем реквизит Владелец и выберем правильного контрагента или организацию.

Это позволит восстановить логическую связь в базе без удаления объектов. Если владельца определить невозможно, можно воспользоваться методом «Поиск и замена значений», чтобы перебросить ссылки с «битых» объектов на корректные.

Шаг 4: Альтернативный метод через механизм РИБ

Если объем данных очень велик или XML-выгрузка работает нестабильно, можно рассмотреть метод временного создания Распределенной Информационной Базы (РИБ).

Разберем этот способ подробнее:

1. В рабочей базе и в базе-бэкапе создадим узлы в одном и том же Плане обмена (например, «Полный»).
2. Присвоим им одинаковые коды, чтобы базы «узнали» друг друга.
3. В базе-бэкапе с помощью обработки РегистрацияИзмененийДляОбменаДанными зарегистрируем только нужные нам документы с движениями.
4. Выполним стандартный обмен. Платформа 1С сама позаботится о сохранении UUID и целостности данных.

Этот метод считается более «продвинутым», так как он использует штатные механизмы платформы для синхронизации объектов.

Рекомендации по предотвращению подобных ситуаций

Чтобы избежать повторения инцидента, проанализируем регламент обновлений:

1. Всегда делайте архивную копию непосредственно перед нажатием кнопки «Принять изменения» в конфигураторе. Обновление конфигурации БД — это точка невозврата.

2. Откажитесь от динамических обновлений в крупных базах (УСО, УПП, ERP). Это основной источник повреждения таблиц метаданных.

3. Используйте расширения для хранения самописных объектов, если позволяет версия платформы. В 8.2 это невозможно, но при переходе на 8.3 это значительно обезопасит ваши доработки.

4. Проводите ТиИС сразу после обновления. Ошибка SDBL на ранней стадии лечится гораздо проще, чем спустя неделю активной работы пользователей.

Использование связки из восстановления метаданных через сравнение конфигураций и переноса данных через ВыгрузкаЗагрузкаДанныхXML является «золотым стандартом» решения проблем с исчезновением объектов в 1С 8.2.