← На главную

Приветствуем вас! В практике администрирования и разработки на платформе 1С:Предприятие нередки критические ситуации, когда база данных «умирает» — она перестает запускаться как в режиме «1С:Предприятие», так и в режиме «Конфигуратор». При этом у вас может не оказаться актуальной резервной копии. Единственным спасением становится попытка извлечь данные напрямую из поврежденного файла таблицы (например, 1Cv8.1CD для файлового варианта) с помощью низкоуровневых утилит, таких как легендарная программа Tool_1CD.

Однако здесь мы неизбежно сталкиваемся с серьезным техническим препятствием. Даже если мы создадим абсолютно чистую базу-приемник с точно таким же релизом конфигурации, физические имена таблиц и полей в исходной (поврежденной) базе и в новой чистой базе практически наверняка будут различаться. Например, справочник «Организации» в старой базе может называться Reference120, а в новой — Reference130. Реквизиты внутри этих таблиц также получат другие суффиксы (например, _Fld121 вместо _Fld131).

В этой статье мы подробно разберем, почему возникает эта проблема, как устроен механизм сопоставления метаданных DBNames, и рассмотрим эффективные методы решения этой задачи: от логического переноса через формат XML до прямого редактирования структуры базы данных.

Почему различаются имена таблиц в одинаковых конфигурациях?

Давайте разберем внутреннее устройство платформы 1С. Когда мы создаем объекты метаданных в конфигураторе (справочники, документы, регистры), платформа не создает в СУБД или файле 1CD таблицы с понятными именами вроде «Справочник.Организации». Вместо этого она генерирует системные имена: ReferenceN для справочников, DocumentN для документов, _InfoRegN для регистров сведений, где N — это порядковый номер.

Связь между понятным логическим именем (например, Справочник.Контрагенты), уникальным идентификатором объекта (UUID) и физическим именем таблицы (например, Reference120) хранится в специальной системной таблице базы данных под названием Params в поле с именем dbnames. Этот файл представляет собой бинарные данные, сжатые по алгоритму Deflate.

Порядковые номера таблицам присваиваются динамически в момент создания объекта в конфигураторе или в процессе обновления конфигурации. Если две базы данных создавались в разное время или обновлялись разными путями (например, одна база обновлялась последовательно через 10 релизов, а вторая была создана сразу из файла поставки новой версии), то последовательность создания таблиц будет отличаться. Соответственно, справочник, который в старой базе получил номер 120, в новой базе легко может получить номер 130. Прямое бинарное копирование таблиц в таком случае приведет к полной неработоспособности базы данных.

Шаг 1. Попытка первичной реанимации исходной базы

Прежде чем приступать к сложному низкоуровневому переносу таблиц, давайте проанализируем состояние «мертвой» базы. Часто база не открывается из-за незавершенных транзакций, сбоев динамического обновления («демонического» обновления) или повреждения индексных файлов. Перед извлечением таблиц выполним следующие действия:

1. Резервное копирование: Обязательно сделайте копию файла 1Cv8.1CD перед любыми манипуляциями!
2. Очистка временных файлов и кэша: Удалите все файлы блокировок и временные файлы в каталоге базы данных (файлы с расширениями *.1CLa, *.1CLck).
3. Утилита chdbfl.exe: Запустите стандартную утилиту проверки файловой базы данных chdbfl.exe, которая находится в папке bin установленной платформы 1С. Отметьте флаг «Исправлять обнаруженные ошибки».
4. Очистка таблиц динамического обновления в Tool_1CD: Откройте базу в утилите Tool_1CD. Найдите таблицы, содержащие конфигурацию (Config, ConfigSave). Очень часто сбой происходит из-за того, что в базе зависли остатки «демонического» обновления. Попробуйте очистить таблицу ConfigSave или откатить конфигурацию к стабильной версии, удалив записи, связанные с незавершенным обновлением.

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

Способ 1. Логический перенос данных через формат XML (Рекомендуемый метод)

Это самый безопасный и универсальный способ. Вместо того чтобы переносить таблицы физически и пытаться сопоставить их внутреннюю структуру, мы выгрузим данные на логическом уровне в универсальный формат XML, а затем загрузим их в чистую базу стандартными средствами платформы 1С.

Давайте рассмотрим этот процесс пошагово:

1. Выгрузка данных из поврежденной базы: Открываем поврежденную базу в программе Tool_1CD. Утилита позволяет экспортировать содержимое таблиц справочников и документов в XML-файлы. На этом этапе программа автоматически преобразует физические структуры (строки и колонки таблицы Reference120) в структурированный XML-документ, где элементы будут описаны понятными именами метаданных.
2. Создание чистой базы: Создаем пустую информационную базу и загружаем в нее ту же самую конфигурацию (с помощью файла выгрузки *.cf, который можно получить из аналогичного здорового релиза или попробовать извлечь из таблицы Config старой базы через ту же Tool_1CD).
3. Загрузка данных с помощью обработок: Для импорта полученных XML-файлов в чистую базу нам понадобится внешняя обработка. На профессиональных ресурсах доступны готовые универсальные обработки, такие как «Загрузка документов и справочников из файлов XML, созданных утилитой Tool_1CD».
4. Принцип работы обработки: Обработка считывает XML-файл, сопоставляет объекты по их уникальным идентификаторам (UUID) или по ключевым полям поиска (например, Код, Наименование, ИНН) и программно создает новые элементы справочников и документы в чистой базе. Сама платформа 1С при этом автоматически записывает данные в новые физические таблицы (например, уже в Reference130 вместо старой Reference120).

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

Способ 2. Использование инструмента «Замена TREF» в Tool_1CD

Если вы все же решили переносить таблицы физически (путем копирования бинарных данных через утилиту), вам придется решить проблему битых ссылок. Давайте разберем, что такое _TREF и почему ссылки ломаются при переносе таблиц.

В базах данных 1С ссылки на другие объекты хранятся в виде пары значений: идентификатор типа (номера таблицы, на которую указывает ссылка, — это поле с суффиксом _TREF) и уникальный идентификатор самой записи (поле _RTRef или UUID). Если вы просто скопируете таблицу документов из старой базы, где ссылка на контрагента указывала на таблицу 120 (Reference120), в новую базу, где контрагенты лежат в таблице 130 (Reference130), все ссылки в документах станут «битыми» (в интерфейсе вы увидите ошибку «Объект не найден»).

Для решения этой проблемы автор утилиты Tool_1CD предусмотрел специальный механизм:

1. Перейдите на вкладку «Дополнительно» в интерфейсе программы Tool_1CD.
2. Найдите раздел работы с таблицами и поле «Файл соответствия номеров».
3. Создайте текстовый файл сопоставления. В этом файле укажите старые номера таблиц и их новые соответствия в чистой базе. Пример формата записи:
   Скопировать код

   
   Reference120=Reference130
   Document50=Document55
   

4. Нажмите кнопку «Замена TREF». Утилита автоматически просканирует все переносимые таблицы и пересчитает ссылки во всех полях _TREF, заменив старые идентификаторы таблиц на новые.

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

Способ 3. Продвинутый уровень: ручное редактирование схемы DBNames

Этот способ подходит для опытных системных администраторов баз данных и разработчиков, работающих с клиент-серверным вариантом (SQL-серверы MS SQL, PostgreSQL и др.). Мы можем заставить платформу 1С думать, что старые физические таблицы соответствуют новым объектам конфигурации, путем изменения системной таблицы Params.

Давайте разберем алгоритм действий:

1. Извлечение структуры DBNames: С помощью SQL-запроса выгружаем бинарное поле из таблицы Params, где хранится запись с ключевым именем dbnames: SELECT [BinaryData] FROM [Params] WHERE [FileName] = 'dbnames'
2. Рапаспаковка данных: Поскольку данные сжаты алгоритмом Deflate, их необходимо распаковать. Для этого можно использовать скрипт на Python или специализированную внешнюю обработку (например, для разбора схемы DB).
3. Редактирование сопоставлений: Полученный текстовый файл содержит массив соответствий уникальных идентификаторов метаданных (UUID) и номеров физических таблиц СУБД. Нам нужно заменить UUID объектов конфигурации из старой базы на UUID аналогичных объектов из новой базы, сохранив при этом физические имена таблиц (то есть оставив старые номера Reference120 привязанными к новым метаданным).
4. Запаковка и загрузка обратно: Сжимаем отредактированный файл обратно с помощью Deflate и записываем его обратно в таблицу Params базы данных на SQL-сервере с помощью UPDATE-запроса.

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

Резюме и рекомендации

Мы проанализировали различные варианты решения проблемы несовпадения имен таблиц в базах 1С. Давайте подведем итоги:

• Если вам нужно гарантированное, безопасное и простое решение — используйте Способ 1 (выгрузка и загрузка через XML). Это займет чуть больше времени на выполнение импорта, но убережет вас от ошибок ссылочной целостности.
• Если объемы данных огромны, и XML-перенос не справляется, воспользуйтесь Способом 2 (Замена TREF в Tool_1CD), предварительно тщательно подготовив файл сопоставления таблиц.
• Всегда делайте резервные копии баз данных перед началом любых технических работ. Регулярно настраивайте автоматическое резервное копирование, чтобы вам никогда не приходилось восстанавливать данные на уровне двоичного кода таблиц!