При администрировании распределенных информационных баз (РИБ) на платформе 1С:Предприятие, особенно при использовании конфигурации "1С:Розница", специалисты могут столкнуться с критической ошибкой после обновления центрального узла. Ситуация выглядит следующим образом: центральная база (ЦБ) на SQL сервере обновлена успешно, но при попытке синхронизации с периферийной базой (ПБ), работающей в файловом варианте, обмен прерывается с сообщением о том, что не обнаружена таблица с именем вида RefSInfXXXXX (например, RefSInf21018).
В этой статье мы подробно разберем, что скрывается за этим сообщением, почему возникает данная проблема, как идентифицировать потерянные данные и, самое главное, как восстановить работоспособность периферийного узла, даже если отсутствуют актуальные резервные копии.
Прежде чем приступать к "лечению", давайте разберемся в анатомии базы данных 1С. Сообщение об ошибке содержит имя таблицы, которое может показаться случайным набором символов, но это не так.
Внутри физической структуры базы данных (будь то файл 1Cv8.1CD или таблицы на SQL Server) платформа хранит данные не с теми именами, которые мы видим в Конфигураторе (например, Справочник.Номенклатура), а с внутренними идентификаторами.
Префикс RefSInf расшифровывается как Reference Static Information. Это служебная таблица, сопровождающая справочники. Она предназначена для хранения информации о предопределенных элементах справочника. Она связывает имя предопределенного элемента (заданное в конфигураторе) с его ссылкой (GUID) в таблице данных.
Важно понимать: Даже если вы не создавали предопределенные элементы в конкретном справочнике вручную, платформа может создавать эту таблицу для системных нужд или если возможность наличия предопределенных элементов заложена в метаданных.
Проанализируем ситуацию, описанную в исходной теме. Проблема возникла после обновления конфигурации. Дело в том, что в определенных версиях платформы 1С:Предприятие 8.3 (в частности, ветки 8.3.22, 8.3.23 и ранние 8.3.24) был обнаружен серьезный программный дефект (баг).
Суть ошибки заключается в следующем: при выполнении реструктуризации базы данных (процесс, который происходит при обновлении конфигурации), платформа ошибочно помечала пустые таблицы RefSInf как "мусорные" и физически удаляла их из структуры файла базы данных. Однако описание этой таблицы в схеме конфигурации оставалось.
В результате, когда периферийная база пытается обратиться к этой таблице (например, при попытке записать изменения или проверить структуру), она обнаруживает несоответствие: по логике конфигурации таблица должна быть, но физически блок данных отсутствует. Это и вызывает ошибку "Не обнаружена таблица...".
Имя таблицы, указанное в ошибке (например, RefSInf21018), содержит цифровой суффикс, который является частью внутреннего идентификатора. Чтобы понять, какой именно справочник пострадал, нам необходимо сопоставить это "техническое" имя с понятным именем объекта метаданных.
Поскольку центральная база (ЦБ) и периферийная база (ПБ) имеют идентичную конфигурацию (файл .cf), мы можем вычислить соответствие в любой рабочей копии или в самой ЦБ. Для этого воспользуемся встроенной функцией ПолучитьСтруктуруХраненияБазыДанных().
Рассмотрим код, который поможет найти проблемный справочник. Этот код можно выполнить в обработке с произвольным алгоритмом или во внешней обработке:
// Укажите часть имени таблицы, которую выдает ошибка
ЧтоИщем = "_RefSInf";
// Для точного поиска можно указать полный суффикс, например "_RefSInf21018"
// Получаем структуру хранения всей базы данных
// Второй параметр "Истина" означает, что мы хотим получить имена таблиц в терминах СУБД
СтруктураХранения = ПолучитьСтруктуруХраненияБазыДанных(, Истина);
Для Каждого Таблица Из СтруктураХранения Цикл
// Проверяем, содержит ли имя таблицы искомый фрагмент
Если СтрНайти(Таблица.ИмяТаблицыХранения, ЧтоИщем) > 0 Тогда
// Выводим имя таблицы БД и соответствующий ей объект метаданных
Сообщить("Таблица БД: " + Таблица.ИмяТаблицыХранения + " ---> Объект: " + Таблица.Метаданные);
КонецЕсли;
КонецЦикла;
В результате выполнения этого кода в окне сообщений вы увидите список соответствий, например:
_RefSInf1339 (Справочник.ВидыВыплат)_RefSInf21018 (Справочник.ЧекиККМ)Так мы точно узнаем, какой справочник "потерял" таблицу предопределенных данных.
Поскольку проблема связана с ошибкой платформы, простое "Тестирование и исправление" на старой версии платформы может не помочь или усугубить ситуацию, повторно удаляя таблицы. Рассмотрим правильную последовательность действий.
Первым и обязательным шагом является обновление платформы 1С:Предприятие на всех узлах (и в центре, и на периферии). Ошибка с удалением таблиц RefSInf была официально признана фирмой "1С" и исправлена.
Вам необходимо установить версию не ниже 8.3.24.1667. Если вы используете другую ветку (например, 8.3.25), убедитесь, что в ней также применены соответствующие исправления.
Внимание: Попытки исправления базы на версии платформы с ошибкой (например, 8.3.24.1586) могут привести к повторному возникновению проблемы.
Если у вас файловая периферийная база и нет резервной копии, восстановление средствами SQL невозможно. Однако, особенность файлового варианта работы 1С играет нам на руку. В файловой базе имена таблиц формируются детерминировано на основе уникальных идентификаторов (UUID) объектов метаданных.
Это означает, что если мы возьмем конфигурацию (файл .cf) из Центральной Базы и создадим из нее новую пустую файловую базу, то имена таблиц (RefSInf...) в этой новой базе будут точно такими же, как в нашей сломанной периферийной базе.
Алгоритм действий:
.cf файл) из Центральной базы..cf.1Cv8.1CD (в сообществе специалистов часто используют утилиты типа Tool1CD).Работа с инструментом восстановления:
1Cv8.1CD новой (донорской) базы.RefSInf21018).1Cv8.1CD поврежденной периферийной базы.После того как мы физически "подложили" недостающую таблицу, необходимо заставить платформу 1С корректно ее принять и проиндексировать.
Выполните следующие действия строго на исправленной версии платформы (8.3.24.1667 или новее):
Реструктуризация на исправленной платформе корректно обработает восстановленную таблицу RefSInf, пропишет необходимые связи и не удалит ее, так как баг в этой версии устранен.
В ходе обсуждения часто возникает вопрос: почему мы не можем просто скопировать таблицу из Центральной базы (SQL) в Периферийную? Или почему мы не нашли таблицу с таким же именем в SQL Management Studio?
Давайте проясним этот технический момент:
_Reference123) генерируются в момент создания базы и зависят от порядка создания объектов и внутренней таблицы dbschema. В разных базах (даже с одинаковой конфигурацией) имена таблиц для одного и того же справочника будут отличаться..cf файла, внутренние идентификаторы таблиц с высокой долей вероятности будут совпадать.Именно поэтому метод с созданием "пустой базы-донора" работает для восстановления файловых баз, но перенос "сырых" данных напрямую из SQL в файл невозможен из-за различия в именовании и структуре хранения.
Чтобы избежать подобных ситуаций в будущем, рекомендуем:
resetMasterNode (отвязку от главного узла), так как это может усложнить последующую синхронизацию. Сначала проведите диагностику физической целостности базы.