Переезд крупной информационной базы (например, 1С:УПП 1.3) на новую серверную инфраструктуру — это всегда сложный процесс, сопряженный с риском возникновения труднодиагностируемых ошибок. Одной из наиболее серьезных проблем является ситуация, когда база формально перенесена, но пользователи не могут создать новые элементы справочников, а система выдает загадочные сообщения об ошибках SDBL или некорректно обрабатывает перечисления. Разберем детально, почему это происходит и как восстановить работоспособность системы.
Рассмотрим типовую ситуацию: база мигрирует с SQL 2008 на SQL 2016 с одновременным обновлением платформы до версии 8.3.15. В процессе возникают симптомы: невозможность программного или ручного добавления элементов в справочник Номенклатура, ошибка SDBL: Таблица или поле Number не содержится в разделе FROM и странное поведение перечислений в отладчике (значение Неопределено).
Проанализируем причины. Основная проблема часто заключается в рассинхронизации логической структуры (описанной в конфигурации) и физической структуры таблиц в СУБД. Это происходит из-за некорректных методов переноса (например, прямое копирование mdf-файлов между разными версиями SQL) или накопленных ошибок в системных таблицах 1С еще на старом сервере.
Многие системные администраторы пытаются создать новую базу в SQL и «подцепить» к ней файлы данных. Это не самый надежный метод для 1С. Разберем правильный алгоритм восстановления:
Restore Database из .bak файла. При этом не создаем заранее пустую базу. SQL Server должен сам развернуть структуру из архива.8.3.12.1790 для первоначального запуска и проверки.Ошибка Таблица или поле Number не содержится в разделе FROM указывает на то, что слой SDBL (внутренний механизм 1С для работы с данными) не может сопоставить запрос к системным полям. Посмотрим, как это лечится:
Очистка серверного кэша: Остановим службу 1С:Предприятия. Перейдем в каталог reg_1541 (или тот, где хранятся данные кластера) и удалим папку с GUID нашей базы. Там хранятся описания метаданных, которые могли «зависнуть» в старом состоянии.
Сброс соответствий имен: Если очистка кэша не помогла, можно прибегнуть к радикальному методу в SQL (предварительно сделав бэкап):
-- Удаление записи о соответствии имен из таблицы Config
DELETE FROM Config WHERE [FileName] = 'dbNames'
После выполнения этого запроса при следующем запуске Конфигуратора система попытается пересобрать внутреннюю карту соответствий объектов. Затем выполним Тестирование и исправление с установленной галочкой «Реструктуризация таблиц информационной базы».
Если справочник Номенклатура не записывается из-за того, что предлагает уже существующие номера, нам необходимо сбросить состояние нумератора. Рассмотрим программный способ решения этой задачи.
Воспользуемся встроенным методом ОбновитьНумерациюОбъектов. Это заставит 1С пересчитать последний использованный номер в базе, исходя из реально существующих записей в таблицах.
// Программный вызов обновления нумерации для конкретного справочника
МетаданныеОбъекта = Метаданные.Справочники.Номенклатура;
ОбновитьНумерациюОбъектов(МетаданныеОбъекта);
Сообщить("Нумерация справочника Номенклатура успешно обновлена!");
Если это не помогает, выясним причину глубже. Возможно, в базе появились записи-«призраки» с некорректными или пустыми ссылками (GUID). Проанализируем таблицу справочника в SQL на наличие записей с нулевым идентификатором (0x0000...). Если такие записи есть, их нужно удалить средствами SQL, так как они блокируют уникальный индекс при попытке создания нового элемента.
Ситуация, когда новые перечисления видны в метаданных, но показывают Неопределено в режиме предприятия, — классический признак «кривого» динамического обновления. Система считает, что данные есть, но не может их инициализировать.
Разберем шаги по исправлению:
.cf, полностью очистим таблицу Config в SQL и загрузим .cf обратно. Это «прошьет» метаданные начисто.Поскольку оригинальный сервер «умер», велика вероятность физического повреждения страниц данных. Обязательно выполним проверку средствами SQL Server:
-- Проверка физической и логической целостности базы
DBCC CHECKDB ('ИмяВашейБазы') WITH NO_INFOMSGS, ALL_ERRORMSGS;
Если команда вернет ошибки, необходимо использовать восстановление с параметром REPAIR_ALLOW_DATA_LOSS, хотя это крайняя мера. Лучше попытаться выгрузить данные через обработку «Выгрузка и загрузка данных XML» в абсолютно новую, пустую базу. Этот метод хорош тем, что он переносит данные на уровне объектов 1С, полностью игнорируя ошибки структуры на уровне таблиц SQL.
Подводя итог, отметим: при миграции критически важно соблюдать последовательность действий и не пытаться «чинить» базу только на уровне платформы, если проблема кроется в несоответствии версий СУБД и битых индексах. Комплексный подход — от SQL-запросов до обновления нумерации — позволит вернуть базу в строй даже после серьезного сбоя сервера.