Каждый практикующий разработчик или системный администратор 1С рано или поздно сталкивается с ситуацией, когда типовое обновление конфигурации 1С:Зарплата и управление персоналом (ЗУП) 3.1 неожиданно прерывается критическим сбоем. Ситуация усложняется в разы, если обновляемая база является нетиповой — содержит множество доработок, кастомных документов, справочников и регистров.
Симптомы проблемы могут проявляться по-разному: платформа сообщает, что «файл не содержит доступных обновлений», отказывается выгружать конфигурацию поставщика, выдает ошибку файловой операции или аварийно завершает работу с пугающим сообщением SDBL ConfigVersion в разделе FROM. Давайте вместе разберем причины возникновения этой проблемы и рассмотрим подробные, проверенные на практике методы её решения — как стандартными средствами конфигуратора, так и на уровне СУБД MS SQL Server.
Прежде чем приступать к активным действиям, проанализируем ситуацию и поймем, что именно происходит «под капотом» платформы 1С:Предприятие. В любой базе данных на поддержке одновременно хранятся три конфигурации:
Основными причинами разрушения связи между ними являются:
Config СУБД может произойти сбой транзакции (например, из-за нехватки оперативной памяти или сетевого таймаута).ConfigVersion. Если структура базы была повреждена при предыдущих неудачных обновлениях, это поле отсутствует или содержит некорректный тип данных, что делает запуск базы в принципе невозможным.Ниже мы подробно разберем три проверенных метода восстановления работоспособности базы данных.
Важное предупреждение: перед выполнением любых шагов из любой инструкции обязательно создайте резервную копию базы данных! Если база файловая — скопируйте файл 1Cv8.1CD, если серверная — сделайте полную резервную копию (бэкап) средствами MS SQL Server или PostgreSQL.
Этот метод является классическим и наиболее безопасным для доработанных конфигураций. Он позволяет полностью перезаписать поврежденную конфигурацию поставщика в системных таблицах, не затронув при этом физические таблицы СУБД, где хранятся данные ваших кастомных объектов.
Рассмотрим процедуру по шагам:
Шаг 1. Экспорт рабочей конфигурации со всеми вашими изменениями
Запустите Конфигуратор поврежденной базы данных. Перейдите в меню Конфигурация — Сохранить конфигурацию в файл.... Укажите имя файла, например, my_work_custom.cf, и сохраните его на диск. В этом файле будут содержаться все ваши доработки вместе с типовым кодом.
Шаг 2. Полное снятие конфигурации с поддержки
Нам необходимо полностью очистить базу от поврежденных блоков конфигурации поставщика. Для этого перейдите в меню Конфигурация — Поддержка — Настройка поддержки. В открывшемся окне нажмите кнопку Снять с поддержки. Подтвердите действие. Желтый кубик поддержки исчезнет, а конфигурация станет полностью редактируемой.
Шаг 3. Загрузка чистого оригинального CF-файла текущего релиза
Для этого шага вам понадобится чистый, не измененный файл конфигурации (расширение .cf) именно того релиза, на котором сейчас находится ваша база (например, 3.1.11.68). Его можно получить, установив полный дистрибутив этого релиза из личного кабинета портала 1С или ИТС, либо выгрузить из чистой базы аналогичной версии.
В Конфигураторе выберите пункт меню Конфигурация — Загрузить конфигурацию из файла... и укажите этот оригинальный чистый .cf. Платформа предупредит вас, что конфигурация будет полностью заменена. Соглашайтесь.
Шаг 4. Отказ от немедленного применения изменений (Критически важно!)
После завершения загрузки платформа выдаст диалоговое окно с вопросом: «Обновить конфигурацию базы данных?».
Внимание: на этот вопрос необходимо ответить НЕТ!
Если вы нажмете «Да», платформа выполнит реструктуризацию таблиц СУБД, и все ваши кастомные документы, справочники и регистры, которых нет в чистом типовом файле, будут безвозвратно удалены вместе с данными!
Шаг 5. Сравнение и объединение с вашим рабочим файлом
Теперь мы имеем чистую конфигурацию поставщика в оперативной памяти Конфигуратора, но нам нужно вернуть на место все наши доработки. Для этого выберите пункт меню Конфигурация — Сравнить, объединить с конфигурацией из файла... и выберите файл my_work_custom.cf, который мы сохранили на Шаге 1.
Платформа произведет сравнение. В открывшемся окне сравнения и объединения убедитесь, что стоят флажки напротив всех измененных и добавленных вами объектов. Нажмите кнопку Выполнить. Ваши кастомные метаданные аккуратно наложатся поверх чистой структуры поставщика.
Шаг 6. Финальное обновление базы данных
Только теперь, когда все доработки вернулись на свои места, можно нажать клавишу F7 (команда Конфигурация — Обновить конфигурацию базы данных). Программа выполнит реструктуризацию. Все ваши данные останутся в полной сохранности, а конфигурация поставщика будет полностью исцелена и перезаписана.
После этого вы можете штатно запускать обновление на следующий релиз (например, на 3.1.11.106).
Если база данных работает в клиент-серверном варианте, а Конфигуратор вообще отказывается запускаться, выдавая ошибки SDBL или падая при попытке снять конфигурацию с поддержки, мы можем решить проблему напрямую через СУБД. Проанализируем, как исправить таблицы метаданных с помощью SQL-запросов в SQL Server Management Studio (SSMS).
Часто сбои происходят из-за того, что в служебной таблице ConfigSave зависают остаточные данные от прошлых неудачных сессий обновления. Очистим эту таблицу безопасной командой:
-- Перед выполнением убедитесь, что все пользователи вышли из базы!
USE [Имя_Вашей_Базы_ЗУП];
GO
TRUNCATE TABLE dbo.ConfigSave;
GO
Эта команда мгновенно удаляет все «демонические» и незавершенные транзакции обновлений, позволяя Конфигуратору запуститься в штатном режиме.
Если при попытке сохранить конфигурацию поставщика или при обновлении СУБД возвращает ошибку из-за слишком большого размера бинарных данных в таблице Config, мы можем принудительно удалить проблемные строки конфигурации поставщика, размер которых превышает критический лимит (обычно это файлы метаданных поставщика размером более 120 МБ):
USE [Имя_Вашей_Базы_ЗУП];
GO
DELETE FROM dbo.Config WHERE DataSize > 125829120;
GO
После выполнения этого запроса поврежденные блоки конфигурации поставщика будут удалены. База запустится в Конфигураторе, но будет числиться снятой с поддержки. Вам останется лишь накатить оригинальный cf файл нужной версии методом сравнения-объединения, как описано в Меоде 1.
Это самый быстрый и изящный способ реанимации крупных серверных баз. Если у вас есть чистая демонстрационная или пустая база ЗУП абсолютно того же релиза, который сейчас развернут у вас (например, 3.1.11.68), мы можем просто заменить поврежденную таблицу метаданных Config рабочей базы на полностью исправную таблицу из донора:
-- Внимание: обе базы должны быть на одном и том же релизе конфигурации!
USE [Имя_Больной_Базы_ЗУП];
GO
-- Очищаем поврежденную таблицу конфигурации
DELETE FROM [Имя_Больной_Базы_ЗУП].[dbo].[Config];
GO
-- Копируем чистую конфигурацию из донорской базы
INSERT INTO [Имя_Больной_Базы_ЗУП].[dbo].[Config]
SELECT * FROM [Имя_Здоровой_Базы_ЗУП].[dbo].[Config];
GO
Этот SQL-скрипт за секунды восстанавливает целостность метаданных конфигурации поставщика, возвращает «замочки» поддержки в Конфигураторе рабочей базы и полностью убирает ошибки SDBL без утомительных процедур загрузки и выгрузки файлов.
Иногда физическая структура базы данных в порядке, но платформа продолжает выдавать ошибку ConfigVersion в разделе FROM из-за закешированных сервером 1С устаревших метаданных. Локальная очистка кэша на компьютере пользователя в этом случае бесполезна. Нам необходимо произвести очистку серверного кэша.
Выполните следующие действия по шагам:
services.msc, служба 1C:Enterprise 8.3 Server Agent).C:\Program Files\1cv8\srvinfo\ или C:\Program Data\1C\1cv8\).reg_1541). Внутри нее будут находиться папки с длинными уникальными идентификаторами баз данных (UUID).snccntry, reg_1541\snccntry и временные файлы. Ни в коем случае не удаляйте файл 1CV8Reg.lst!Если база зависла в неопределенном состоянии «Конфигурация базы данных не соответствует ожидаемой», и вы не можете войти ни в режим Предприятия, ни в Конфигуратор, воспользуйтесь механизмом принудительного отката конфигурации к последней стабильной версии метаданных.
Для этого запустите командную строку Windows (CMD) от имени администратора и выполните команду запуска платформы со служебным ключом:
"C:\Program Files\1cv8\8.3.15.2000\bin\1cv8.exe" DESIGNER /S "ИмяСервера\ИмяБазы" /RollbackCfg /N "Администратор" /P "Пароль"
(Не забудьте подставить в команду ваш актуальный путь к исполняемому файлу платформы 1С, имя сервера, имя базы и учетные данные администратора).
Платформа выполнит принудительную отмену транзакции реструктуризации и вернет базу к работоспособному состоянию, после чего вы сможете безопасно применить Метод 1 для исправления конфигурации поставщика.
Мы детально проанализировали проблему сбоя обновления ЗУП 3.1 и выявили ключевые методы борьбы с повреждениями метаданных. Чтобы свести к минимуму риск возникновения подобных ситуаций в будущем, рекомендуем соблюдать простые правила эксплуатации:
rphost сервера 1С.