При активном внедрении и доработке конфигураций с использованием механизмов расширений в платформе 1С:Предприятие 8 разработчики часто сталкиваются с непредвиденным поведением базы данных. Одной из наиболее критичных проблем является невосстановимая ошибка SDBL при попытке записи или проведения документов. Текст ошибки выглядит следующим образом:
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm: Ошибка SDBL: Поле FldXXXXX таблицы DocumentXXXX не может принимать значение NULL
Типичные административные действия, такие как очистка кэша конфигурации или стандартное тестирование и исправление (ТиИ), в данном случае не приносят результата. В рамках этой статьи мы подробно проанализируем природу этой ошибки, выясним причины ее возникновения и рассмотрим пять эффективных методов исправления ситуации как для файловых, так и для клиент-серверных информационных баз. Для автоматизации подобных технических операций по расписанию инструмент для пакетного тестирования и обновления 1С позволяет выполнять регламентные работы в тихом режиме.
Для того чтобы успешно бороться со сбоем, разберем физические процессы, происходящие на уровне СУБД при использовании расширений. Когда программист добавляет новые реквизиты к стандартным объектам конфигурации (например, к документу ЗаказКлиента) через расширение, платформа производит следующие действия:
ЗаказКлиента соответствует системное имя Document406)._Fld26726 и _Fld26744).Проблема возникает в момент некорректного обновления конфигурации, непредвиденного сбоя СУБД или неправильного удаления расширения. Логическая структура метаданных очищается: Конфигуратор больше не видит эти реквизиты, они исчезают из схемы данных 1С. Однако физические колонки в таблице базы данных СУБД остаются нетронутыми. Они становятся так называемыми «фантомными» или «сиротскими» полями.
При записи любого документа транслятор запросов 1С (SDBL) формирует SQL-запрос к таблице. Платформа обращается к физической таблице базы данных, видит там незарегистрированные колонки, у которых на уровне СУБД стоит признак NOT NULL, но, поскольку логически этих полей в конфигурации больше нет, система не передает в них никаких значений. Возникает закономерный конфликт ограничений СУБД, база данных аварийно прерывает транзакцию и возвращает пользователю ошибку SDBL.
Прежде чем приступать к исправлению, нам необходимо точно выяснить, какому объекту конфигурации принадлежит таблица Document406 и какие поля вызывают ошибку. Для этого мы можем использовать несколько инструментов:
DBStorageStructureInfo). С ее помощью можно быстро сопоставить физические имена таблиц СУБД (например, _Document406) с объектами метаданных 1С.Проанализируем программный способ получения структуры хранения. Для этого можно использовать следующий код:
ТаблицаСтруктуры = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого СтрокаТаблицы Из ТаблицаСтруктуры Цикл
Если СтрокаТаблицы.ИмяТаблицыХранения = "Document406" Тогда
Сообщить("Имя объекта в конфигурации: " + СтрокаТаблицы.ИмяТаблицы);
КонецЕсли;
КонецЦикла;
Выполнив этот код, мы точно определим, что таблица Document406 соответствует документу ЗаказКлиента. Теперь, зная проблемный объект, перейдем к методам исправления структуры БД. Для быстрого сопоставления таблиц и полей без написания кода можно использовать обработку для анализа структуры хранения базы данных.
Важно: Перед выполнением любых дальнейших шагов обязательно создайте резервную копию вашей информационной базы (копию файла 1Cv8.1CD для файлового варианта или бэкап базы в консоли СУБД для клиент-серверного)!
Это самый простой и безопасный способ, который можно выполнить непосредственно средствами платформы 1С без использования стороннего софта. Он отлично подходит как для файловых, так и для клиент-серверных баз.
Рассмотрим этот алгоритм по шагам:
ЗаказКлиента).ВременныйРеквизитТест) и простейший тип данных, например, Булево.В этот момент платформа 1С понимает, что структура таблицы _Document406 изменилась, и принудительно запускает механизм реструктуризации таблицы на уровне СУБД. Во время этого процесса платформа пересоздает таблицу по актуальной логической схеме, очищая старые фантомные колонки, у которых отсутствовали имена в метаданных.
После успешного обновления выполните завершающие шаги:
ВременныйРеквизитТест.Таблица примет свой первоначальный чистый вид, а ошибочные колонки _Fld26726 и _Fld26744 будут окончательно удалены из физической структуры БД.
Если способ с реструктуризацией не помог или структура базы сильно повреждена, можно воспользоваться стандартным механизмом логического импорта/экспорта данных 1С.
Разберем, почему этот метод работает. При выгрузке информационной базы в файл резервной копии (формат .dt) платформа не копирует таблицы СУБД «как есть» вместе со всеми физическими багами. Вместо этого система последовательно считывает данные строго в соответствии с текущей логической структурой метаданных основной конфигурации. Весь «мусор» на уровне СУБД, включая неопознанные фантомные колонки, просто игнорируется и не попадает в итоговый файл.
Выполним процедуру по шагам:
.dt на жесткий диск..dt.После окончания загрузки таблица Document406 будет создана заново, строго по правильной схеме, и ошибка SDBL будет устранена.
Если база данных имеет файловый формат (файл 1Cv8.1CD), мы не можем подключиться к ней через SQL-консоль. Однако мы можем исправить физическую структуру базы напрямую с помощью специализированных утилит, таких как Tool1CD или библиотеки 1CDLib.
Проанализируем этот процесс:
1Cv8.1CD._Document406._Fld26726 и _Fld26744.После сохранения закройте утилиту и запустите базу в режиме «1С:Предприятие». Документы начнут записываться в штатном режиме. Для автоматизации проверки записи документов без ручного ввода можно настроить сценарий в платформе для создания программных роботов.
Если ваша информационная база развернута на сервере под управлением MS SQL Server или PostgreSQL, исправить структуру СУБД можно с помощью прямого выполнения SQL-запроса.
Разберем по шагам, как это сделать на примере MS SQL Server:
ALTER TABLE _Document406 DROP COLUMN _Fld26726;
ALTER TABLE _Document406 DROP COLUMN _Fld26744;
После выполнения запроса СУБД мгновенно удалит фантомные колонки, восстановив работоспособность транзакций SDBL без необходимости перезапуска службы сервера 1С.
Иногда остаточные связи поврежденных расширений хранятся в системных таблицах самой платформы 1С. Для полной принудительной очистки конфигурации от остатков расширений можно использовать запуск Конфигуратора через командную строку со специальным ключом очистки.
Для выполнения этой операции выполните команду в командной строке ОС (cmd):
"C:\Program Files\1cv8\8.3.14.1694\bin\1cv8.exe" DESIGNER /F "C:\PathToYourBase" /N "Администратор" /P "Пароль" /DeleteCfg -AllExtensions
Параметр /DeleteCfg -AllExtensions полностью очистит базу данных от всех загруженных расширений и связанных с ними конфигурационных кэшей, что позволит сбросить некорректные настройки СУБД. Для массового управления и отключения расширений в режиме предприятия подойдёт обработка для групповой работы с расширениями базы.
Чтобы избежать появления подобных системных сбоев при обновлении конфигураций или удалении расширений, необходимо придерживаться строгой последовательности действий при разработке.
Правильный регламент удаления расширений, содержащих собственные реквизиты:
Соблюдение этой простой последовательности гарантирует чистоту физической структуры СУБД и убережет вашу базу данных от критических ошибок SDBL. При необходимости проконтролировать корректность бухгалтерских данных после завершения работ можно автоматически сверить проводки между базами 1С.