При обновлении типовых конфигураций 1С, особенно таких тяжеловесных, как 1С:Бухгалтерия предприятия 3.0, специалисты часто сталкиваются с ситуацией, когда процесс прерывается аварийно. Это приводит к крайне неприятному состоянию базы: основная конфигурация и конфигурация поставщика уже обновлены, а конфигурация базы данных осталась старой и отказывается обновляться из-за внутренних ошибок структуры. Рассмотрим подробно, как выйти из этой ситуации, проанализируем причины возникновения ошибки SDBL и разберем работающие методы восстановления работоспособности системы.
Ситуация обычно развивается по следующему сценарию: в процессе принятия изменений (реструктуризации) конфигуратор закрывается без объяснения причин или выдает ошибку нехватки памяти. После перезапуска при попытке обновить конфигурацию базы данных (нажать "синий бочонок") или выполнить Тестирование и исправление (ТиИ), система выдает сообщение следующего вида:
Ошибка SDBL: Ожидается выражение (pos=2099).
При более детальном анализе через ТиИ всплывает уточнение:
Тип поля CAST(InfoRg31851.Fld31852 AS (STRING(36) VARYING, REF(Reference30824), UNDEFINED)) AS Fld31852 несовместим с типом поля Fld31852
Проанализируем ситуацию: в данном случае ошибка указывает на регистр сведений Очередь сообщений ВетИС. Проблема заключается в том, что платформа пытается преобразовать типы данных в ресурсе или реквизите этого регистра (обычно это составной тип данных, включающий строку и ссылки), но внутренний словарь метаданных (таблица DBSchema) содержит некорректное описание целевого поля. Это происходит из-за того, что предыдущая транзакция обновления была прервана на середине.
Одной из главных причин "вылета" обновления является использование 32-битного клиента 1С. Разберем, почему это критично. Процесс 1cv8.exe в 32-битном исполнении имеет жесткое ограничение адресного пространства — не более 2 Гб. При реструктуризации сложных объектов БП 3.0 платформа строит в оперативной памяти огромные деревья метаданных и временные структуры.
Если объем данных или сложность изменений превышают этот лимит, происходит Out of Memory, и конфигуратор аварийно завершается. В этот момент база остается в "подвешенном" состоянии: файлы конфигурации в таблице Config уже новые, а физические таблицы в SQL еще не приведены к новому виду. Попытки повторного обновления на той же платформе часто приводят к тем же ошибкам SDBL, так как парсер запросов натыкается на логические противоречия в DBSchema.
Наиболее эффективным методом, как показывает практика, является принудительная перезапись метаданных основной конфигурации. Простое "Сравнение и объединение" здесь не поможет, так как оно не обновляет внутреннюю структуру служебных таблиц так радикально, как полная загрузка.
Выполним следующие шаги:
.dt)..cf) именно того релиза, до которого база была "недообновлена" (в нашем примере это 3.0.64.54)..cf файл. Система предупредит, что конфигурация будет полностью заменена — соглашаемся.Важное замечание: Иногда эта операция может не пройти с первого раза из-за кэша сервера 1С. Если ошибка повторилась, попробуйте перезапустить службу 1C:Enterprise Server и повторить загрузку еще раз. Именно повторная загрузка зачастую "проталкивает" корректное сопоставление типов данных.
Если полная загрузка .cf выдает ошибки на этапе обновления БД, проанализируем возможность "мягкого" восстановления структуры. Попробуем выполнить Тестирование и исправление, но с минимально необходимым набором флагов.
Рассмотрим алгоритм действий:
Реструктуризация принудительно пересоздает таблицы в базе данных SQL на основе текущих метаданных основной конфигурации. Если таблицы (как в случае с ВетИС) пустые, процесс пройдет быстро и очистит некорректные записи в DBSchema.
В особо тяжелых случаях, когда конфигуратор не дает сделать ничего, программисту приходится обращаться к SQL-запросам. Рассмотрим, какие таблицы отвечают за хранение состояния конфигурации.
Если база данных "считает", что она находится в процессе редактирования, который нельзя завершить, можно попробовать очистить таблицу временных сохранений конфигурации. Выясним причину, почему 1С "помнит" старую структуру: данные об этом могут кэшироваться в таблице Params.
Пример очистки кэша имен (использовать с осторожностью):
DELETE FROM Params WHERE FileName = 'dbNamesCache'
Также, если конфигурация БД зависла в состоянии обновления, может помочь очистка таблицы ConfigSave:
DELETE FROM ConfigSave
После выполнения этих запросов на уровне SQL, платформа будет вынуждена пересчитать соответствия при следующем запуске конфигуратора, что может устранить ошибку SDBL pos=2099.
Проанализировав ситуацию, мы видим, что корень проблемы кроется в рассинхронизации трех состояний конфигурации: поставщика, основной и базы данных. Для предотвращения подобных ситуаций в будущем рекомендуем придерживаться следующих правил:
Insufficient memory..dt или базы SQL вырос в два раза (например, с 500 Мб до 1 Гб), это верный признак того, что включился режим Редактируется с сохранением поддержки или произошел сбой в таблице Config. В норме объем должен расти незначительно.Подводя итог: если вы столкнулись с ошибкой CAST в регистре ВетИС или ином объекте, не тратьте время на ручное изменение типов этого объекта. Лучшим решением будет загрузка эталонного CF и выполнение полной реструктуризации на 64-битной платформе. Это вернет внутренние словари 1С в консистентное состояние и позволит продолжить штатную эксплуатацию системы.