При переносе информационной базы 1С:Предприятие из клиент-серверного (SQL) варианта в файловый или при переходе на новые релизы платформы (начиная с 8.3.15 и выше) разработчики часто сталкиваются с критическим сбоем СУБД. Ошибка сопровождается системным сообщением вида: «Длина ключа индекса превышает максимально допустимую» с указанием конкретной таблицы, например, _AccumRg18431_ByDims_TSSSSSNN.
В этой статье мы подробно разберем физические причины возникновения этой ошибки, научимся безошибочно определять проблемный объект метаданных в конфигурации и рассмотрим эффективные способы устранения этой несовместимости.
---
Для того чтобы понять природу проблемы, проанализируем ограничения систем управления базами данных (СУБД) и внутренние механизмы платформы 1С:
.dt) или при тестировании и исправлении происходит аварийное завершение работы._ByDims) было принудительно включено скрытое служебное поле хеша измерений _DimHash, а также разделитель итогов _Splitter (если включено разделение итогов). Добавление этих полей увеличило общую длину ключа индекса. В результате базы данных, которые успешно работали на платформе 8.3.11, начали аварийно завершать реструктуризацию при обновлении на современные релизы.---
Рассмотрим детально имя индекса из сообщения об ошибке: _AccumRg18431_ByDims_TSSSSSNN.
_AccumRg18431 — это физическая таблица регистра накопления (Accumulation Register) в базе данных под номером 18431._ByDims — индекс, строящийся по измерениям этого регистра._TSSSSSNN — суффикс типов данных, входящих в этот индекс (T — Дата/Время, S — Строка или составной тип, N — Число). Из структуры видно, что в индекс входят несколько строковых или составных полей, что и приводит к превышению лимита.---
Попытки найти таблицу по имени в конфигураторе «вручную» часто ни к чему не приводят. Нам необходимо сопоставить имя физической таблицы СУБД (в нашем случае _AccumRg18431) с реальным именем регистра в метаданных 1С. В доступной для входа базе найти соответствующий объект и посмотреть его измерения можно через просмотр метаданных и физических таблиц. Обработка не исправляет индекс; совместимость со старыми версиями 8.3 не подтверждена.
Для этого мы воспользуемся встроенной функцией платформы ПолучитьСтруктуруХраненияБазыДанных(). Обратите внимание, что выполнять этот код необходимо в той базе, которая успешно открывается (например, в работающей клиент-серверной версии на старой платформе).
Создадим внешнюю обработку и запустим в ней следующий код:
Процедура ПоискПроблемногоРегистра() Экспорт
ИмяИскомойТаблицы = "_ACCUMRG18431"; // Имя таблицы из ошибки в верхнем регистре
ТаблицыСтруктуры = ПолучитьСтруктуруХраненияБазыДанных(, Истина);
Найден = Ложь;
Для Каждого Таблица Из ТаблицыСтруктуры Цикл
Если ВРег(Таблица.ИмяТаблицыХранения) = ИмяИскомойТаблицы Тогда
Сообщить("====================================================");
Сообщить("Найден проблемный объект метаданных!");
Сообщить("Имя в конфигурации: " + Таблица.ИмяТаблицы);
Сообщить("Назначение: " + Таблица.Метаданные);
Сообщить("====================================================");
Найден = Истина;
Прервать;
КонецЕсли;
КонецЦикла;
Если Не Найден Тогда
Сообщить("Таблица с именем " + ИмяИскомойТаблицы + " не найдена в структуре хранения.");
КонецЕсли;
КонецПроцедуры
Этот код безошибочно укажет нам на конкретный объект метаданных (например, РегистрНакопления.ПродажиКомпании или РегистрСведений.ДополнительныеРеквизиты), из-за которого происходит сбой.
---
В зависимости от архитектурных требований и конечной цели интеграции выберите один из трех вариантов решения.
Если вам необходимо продолжить полноценную работу с базой данных в файловом режиме или обновить платформу, структуру проблемного регистра придется скорректировать в конфигураторе источника:
_ByDims. Если по какому-то строковому полю не требуется вести учет остатков, строить разрезы итогов или выполнять быстрый поиск, его нужно перенести в «Реквизиты» регистра. Реквизиты хранятся в таблице, но не входят в составной индекс и не раздувают его длину.После внесения изменений выполните реструктуризацию базы данных через Конфигуратор (меню Администрирование — Тестирование и исправление с включенным флагом «Реструктуризация таблиц информационной базы»). После этого выгрузка в .dt и загрузка в файловую базу пройдут без ошибок.
Если ваша задача — исключительно перенос справочной информации (например, Контрагентов и Номенклатуры с их реквизитами) из старой базы в новую конфигурацию (например, УТ), то исправлять структуру индексов в старой базе не обязательно.
Поскольку исходная база данных стабильно функционирует на сервере под управлением старого релиза платформы (например, 8.3.11), вы можете получить все необходимые данные напрямую, минуя процедуру создания файловой копии:
V83.COMConnector) или воспользуйтесь встроенными механизмами обмена XML/JSON.В случаях, когда поврежден файл конфигурации .cf и вы не можете загрузить его даже в пустую файловую базу, выполните выгрузку конфигурации в файлы XML на исходном сервере:
---
Ошибка превышения длины ключа индекса — это классическое следствие избыточного проектирования метаданных (хранения длинных строк в разрезах учета). Оптимизация структуры регистров не только решит проблему с совместимостью платформ, но и существенно повысит общую производительность СУБД при расчете итогов и проведении документов.