Ошибка SDBL в 1С: «Таблица не создана в новом поколении»

После обновления 1С база перестала запускаться и показала окно с текстом:

Ошибка SDBL: Таблица InfoRg6991 не создана в новом поколении

Коротко: что делать и чего не делать

Сразу и безопасно:

1. Не перезапускайте обновление «на удачу» — сначала запишите полный текст ошибки и время, когда она появилась.
2. Убедитесь, что у вас есть свежая резервная копия базы до обновления, и никто её не перезаписывает.
3. Выгоните пользователей из базы, чтобы никто не продолжал вводить документы в сломанное состояние.
4. Дальше разбирайтесь на копии базы, а не на рабочей.

Чего делать нельзя:

• создавать, переименовывать или удалять таблицы в SQL-базе руками — структуру таблиц 1С ведёт сама, ручная правка превращает восстановимую ситуацию в невосстановимую;
• ставить эксперименты на единственной рабочей базе, если копии нет;
• запускать одно «лечение» за другим, не записывая, что именно уже пробовали.

Что это за ошибка

SDBL — внутренний язык запросов 1С к своей базе данных. Сообщение говорит: платформа обратилась к служебной таблице (в нашем случае InfoRg6991 — это регистр сведений) и не нашла её в том виде, в котором ожидала после реструктуризации.

Имя таблицы вида InfoRg#### — служебное, оно не совпадает с названием регистра в конфигураторе. Само по себе оно ничего не говорит о причине: важнее, на каком шаге обновления всё остановилось.

Что подтверждено в нашем случае

Чтобы не выдавать догадки за факты, отделим то, что мы наблюдали, от того, что можно предполагать.

Наблюдали:

• ошибка появилась при обновлении 1С, на платформе 8.3.18.1208;
• очистка кеша — и серверного, и пользовательского — результата не дала;
• при заходе в конфигуратор база встретила отдельным сообщением «Пользователь ИБ не идентифицирован»;
• работу удалось восстановить из резервной копии.

Чего мы не проверяли и потому не утверждаем: что именно прервало реструктуризацию в тот раз. Прерванное обновление, нехватка места, обрыв связи с сервером СУБД, параллельный сеанс — всё это правдоподобные версии, но в том инциденте ни одна не была подтверждена.

Безопасная диагностика

Порядок, который не делает хуже:

1. Зафиксируйте факты. Полный текст ошибки (целиком, включая имя таблицы), версия платформы и конфигурации, что именно обновлялось, на каком шаге остановилось.
2. Посмотрите журнал регистрации за время инцидента — там видно, чем закончился сеанс обновления.
3. Технологический журнал — если он включён; специально включать его задним числом смысла нет, записей за прошлое там не появится.
4. Проверьте очевидное на сервере: свободное место на диске с базой и на диске СУБД, доступность сервера 1С и сервера баз данных.
5. Сделайте копию текущего — сломанного — состояния базы, прежде чем что-либо чинить. Она понадобится, если решение придётся искать дальше.
6. Работайте на копии. Проверка и исправление, тестирование и исправление ИБ, повторное обновление — всё это сначала на восстановленной копии, и только потом на рабочей базе.

Отдельно про кеш: чистить серверный и пользовательский кеш — безопасно, и с этого разумно начать. Но если дело не в кеше, повторная чистка ничего не изменит, как и вышло у нас.

Что помогло

В нашем случае базу вернули из резервной копии, снятой до обновления. Это сработало, но это не универсальное лекарство, а способ быстро вернуть бизнесу рабочую базу: причина остаётся неустановленной, и повторное обновление нужно готовить аккуратнее — на копии, с проверкой свободного места и без активных пользователей.

Если резервной копии нет — не импровизируйте с SQL. С этого момента любая неверная попытка стоит дороже: остановитесь и позовите специалиста, пока состояние базы ещё воспроизводимо.

Как понять, что можно продолжать работу

Прежде чем пускать людей в базу после восстановления:

• база открывается и в режиме «Предприятие», и в конфигураторе;
• «Тестирование и исправление» не находит ошибок структуры;
• проведены контрольные операции: открыть последние документы, сформировать привычный отчёт, провести один документ;
• зафиксировано, на какой момент восстановлены данные, и что нужно ввести повторно.

Последний пункт важнее, чем кажется: после восстановления из копии часть работы за день может быть потеряна, и лучше сразу сказать об этом бухгалтеру, чем обнаружить расхождение в отчётности.

Если ошибка повторяется после восстановления и обновление снова падает на том же месте — напишите нам: это уже разбор конкретной базы, а не типовая инструкция.