При работе с конфигурацией 1С:Зарплата и управление персоналом 3.1 (особенно начиная с релизов 3.1.10 и 3.1.11) пользователи и администраторы часто сталкиваются с критической ошибкой SDBL. Эта ошибка может проявляться как в пользовательском режиме (например, при заполнении документа Ведомость на счета или обновлении индекса полнотекстового поиска), так и на этапе обновления конфигурации базы данных. В последнем случае она часто сопровождается сообщением: «Для одного ссылочного кода существует более одной таблицы в базе данных».
Рассмотрим природу этой проблемы, проанализируем причины её возникновения и разберем пошаговые методы её решения, основываясь на технических особенностях платформы 1С:Предприятие 8.3.
Для начала разберем технический аспект. SDBL (Simple Database Layer) — это внутренний слой платформы 1С, который выступает посредником между высокоуровневыми запросами 1С и низкоуровневыми SQL-запросами к системе управления базами данных (СУБД). Когда мы обращаемся к объекту метаданных, например, к справочнику Сотрудники, SDBL транслирует это обращение в запрос к физической таблице ReferenceX в SQL.
Основная причина ошибки «Таблица или поле ID не содержится в разделе FROM» заключается в рассинхронизации между тем, что сервер 1С держит в своей оперативной памяти (кеше метаданных), и тем, что фактически записано в таблицах Config и DBSchema внутри базы данных SQL. Выясним причину этой рассинхронизации. Платформа в целях оптимизации хранит счетчики объектов и карту соответствия таблиц в памяти кластера. Если база данных была восстановлена из бэкапа средствами SQL «поверх» существующей базы без последующего перезапуска службы сервера 1С, счетчик метаданных может «перескочить» или задублироваться.
Проанализируем ситуацию: сервер 1С считает, что данные объекта должны находиться в таблице с определенным номером, но после некорректного обновления или восстановления из бэкапа в этой таблице отсутствует поле ID, либо сама таблица в SQL имеет другую структуру. Это приводит к полному отказу системы выполнять запросы к пораженным объектам.
Как показывает практика, это самое простое и часто самое эффективное решение. Поскольку проблемный счетчик метаданных хранится в памяти процесса rmngr или rphost, его принудительное обнуление помогает восстановить связь. Рассмотрим подробнее шаги:
srvinfo (обычно это C:\Program Files\1cv8\srvinfo). Найдите папку вашей информационной базы (её UID можно посмотреть в консоли администрирования кластера) и удалите содержимое папок snacc и reg_XXXX. Будьте осторожны: не удаляйте файлы конфигурации кластера 1cv8wsrv.lst.После перезапуска сервер будет вынужден заново считать структуру из таблицы DBSchema и сформировать корректную карту соответствия объектов в оперативной памяти.
Проблема тесно связана с конкретными релизами платформы 8.3.13, 8.3.14 и ранними сборками 8.3.15. В этих версиях механизм фоновой реструктуризации часто работал некорректно. Разберем рекомендации по выбору версии:
Если ошибка SDBL блокирует обновление конфигурации базы данных, выдавая список дублирующихся кодов (например, ConstChngR21 и Node21), это означает, что в базе данных зависли «хвосты» от предыдущих неудачных реструктуризаций. Посмотрим, как это лечится штатными средствами:
Запустите Тестирование и исправление (ТиИ) со следующими настройками:
Важно: Перед запуском реструктуризации обязательно создайте резервную копию базы данных. В случае клиент-серверного варианта убедитесь, что в консоли кластера установлена галочка, разрешающая выполнение регламентных заданий и монопольный доступ.
Если перезапуск сервера и ТиИ не помогли, воспользуемся методом полной логической пересборки базы. Рассмотрим этот процесс по шагам:
Администрирование -> Выгрузить информационную базу... и сохраните файл .dt.Администрирование -> Загрузить информационную базу..., выбрав ранее созданный файл .dt.Почему это работает? При выгрузке в .dt 1С не копирует физическую структуру таблиц (номера ReferenceXX), а выгружает только описание объектов и их данные. При загрузке в новую базу платформа создает структуру таблиц «с нуля», присваивая объектам новые, последовательные и непротиворечивые коды. Это полностью устраняет проблему дублирования таблиц и отсутствия полей ID.
Если ошибка возникает при выполнении процедуры Обновление индекса ППД в общем модуле ПолнотекстовыйПоискСервер, это часто указывает на то, что индекс пытается обратиться к уже несуществующим или измененным таблицам. Посмотрим, как это исправить:
Выясним, помогает ли полная очистка индекса. В пользовательском режиме перейдите в раздел Администрирование -> Поддержка и обслуживание -> Полнотекстовый поиск. Нажмите кнопку Очистить индекс, а затем Обновить индекс. Если это не помогает из-за ошибки SDBL, попробуйте программно отключить и включить полнотекстовый поиск следующей командой в консоли кода:
ПолнотекстовыйПоиск.УстановитьИспользованиеПолнотекстовогоПоиска(Ложь);
// Затем удалите файлы из папки Index в каталоге базы данных
ПолнотекстовыйПоиск.УстановитьИспользованиеПолнотекстовогоПоиска(Истина);
ПолнотекстовыйПоиск.ОбновитьИндекс();
Подводя итог, проанализируем ситуацию: в большинстве случаев виновата специфика работы кеша платформы 1С с метаданными СУБД. Чтобы избежать подобных проблем в будущем, придерживайтесь следующих правил:
1C:Enterprise Server.Если вы столкнулись с ошибкой в документе ВедомостьНаСчета после обновления на 3.1.11.106, наиболее быстрым путем решения будет именно перезапуск службы сервера 1С с очисткой папки snacc. Это позволит бухгалтерии продолжить работу без длительного ожидания полной реструктуризации базы.