Как исправить ошибку СУБД «Таблица не найдена» в файловой базе 1С: пошаговое руководство

← На главную

Ошибки формата СУБД в файловых базах 1С (файлы .1CD) — одна из самых серьезных проблем, с которыми может столкнуться администратор или разработчик. Ошибка вида «Ошибка СУБД: Ошибка SQL: Таблица не найдена "_ScheduledJob30396"» означает, что в системном описании структуры базы данных информация о таблице присутствует, но физически в файле базы данных эта таблица отсутствует или повреждена настолько, что платформа не может к ней обратиться. Рассмотрим подробнее, как диагностировать и устранить эту проблему, когда стандартное «Тестирование и исправление» (ТиИ) или утилита chdbfl.exe не помогают.

Выясняем причину и находим виновника

Первым делом нам необходимо понять, какому объекту метаданных соответствует «пропавшая» таблица. Имена в SQL-формате (например, _ScheduledJob30396) не всегда очевидны — для этого подойдёт анализ физической структуры таблиц и индексов базы. Проанализируем ситуацию: чаще всего такие ошибки возникают в таблицах регламентных заданий, итогов или регистрах сведений. Чтобы точно определить объект, воспользуемся встроенной функцией платформы.

Разберем, как получить структуру хранения базы данных. Нам поможет метод ПолучитьСтруктуруХраненияБазыДанных(). Выполним небольшой фрагмент кода во внешней обработке или в консоли кода:


СтруктураИБ = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого СтрокаТаблицы Из СтруктураИБ Цикл
    Если СтрокаТаблицы.ИмяТаблицыХранения = "ScheduledJob30396" 
       Или СтрокаТаблицы.ИмяТаблицыХранения = "_ScheduledJob30396" Тогда
        Сообщить("Объект метаданных: " + СтрокаТаблицы.ИмяТаблицы);
    КонецЕсли;
КонецЦикла;

После того как мы выяснили, что ошибка связана, например, с РегламентноеЗадание.ИзвлечениеТекста, мы можем переходить к активным действиям по восстановлению. Для управления задачами есть консоль управления регламентными и фоновыми заданиями.

Метод 1: Обход ошибки через удаление и восстановление метаданных

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

Создание резервной копии. Это обязательный этап перед любыми манипуляциями с файлом .1CD.
Сохранение конфигурации. Зайдем в Конфигуратор, выберем пункт меню «Конфигурация» — «Сохранить конфигурацию в файл...» (получим файл .cf).
Включение возможности изменения. Если база находится на поддержке, идем в «Конфигурация» — «Поддержка» — «Настройка поддержки» и нажимаем «Включить возможность изменения».
Удаление проблемного объекта. Найдем в дереве метаданных наше регламентное задание (в нашем примере это ИзвлечениеТекста) и удалим его.
Обновление конфигурации базы данных. Нажмем F7. Платформа увидит, что объект удален, и примет изменения, «забыв» о несуществующей таблице.
Восврат конфигурации. Теперь выполним «Конфигурация» — «Загрузить конфигурацию из файла...», выбрав .cf, сохраненный в пункте 2.
Финальное обновление. Снова нажмем F7. Платформа заново создаст структуру таблицы для регламентного задания, но на этот раз она будет чистой и работоспособной.

Метод 2: Решение сопутствующих ошибок при обновлении (Регистры сведений)

Иногда при выполнении пункта 5 предыдущего метода мы можем столкнуться с новой ошибкой, например: «Имеются записи с одинаковыми измерениями» (поможет обработка поиска и удаления дублей в регистрах) в регистре СвязьВидовИФорматовДокументовЭДО. Это происходит из-за того, что при реструктуризации данных платформа пытается пересчитать уникальность записей, а в поврежденной базе или при смене релизов возникли дубли.

Проанализируем ситуацию: если данные в этом регистре не являются критически важными (как в случае с ЭДО, где они часто носят служебный характер), их можно временно очистить. Посмотрим на пример кода, который поможет «грохнуть» записи в проблемном регистре — есть готовая диагностика и удаление поврежденных записей регистров.


&НаСервереБезКонтекста
Процедура ОчиститьРегистрНаСервере()
    НаборЗаписей = РегистрыСведений.СвязьВидовИФорматовДокументовЭДО.СоздатьНаборЗаписей();
    // Мы не устанавливаем отбор, поэтому Записать() просто очистит таблицу
    НаборЗаписей.Записать(); 
КонецПроцедуры

&НаКлиенте
Процедура ВыполнитьОчистку(Команда)
    ОчиститьРегистрНаСервере();
    Сообщить("Регистр успешно очищен, можно продолжать обновление (F7).");
КонецПроцедуры

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

Метод 3: Низкоуровневая конвертация формата (утилита cnvdbfl)

Если конфигуратор вообще не позволяет внести изменения, попробуем изменить формат самой базы. Существует штатная утилита cnvdbfl.exe, которая находится в папке bin установленной платформы. Рассмотрим вариант временного «отката» версии формата базы:

Сконвертируем базу в старый формат (8.2.14): cnvdbfl -c -f 8.2.14 "путь_к_базе".
Попробуем запустить ТиИ или выполнить удаление объекта.
Сконвертируем обратно в актуальный формат: cnvdbfl -c -f 8.3 "путь_к_базе".

Важно: Этот метод рискованный для новых релизов (например, БП 3.0), так как часть метаданных, специфичных для формата 8.3.8 и выше, может быть утрачена. Используйте его только как «средство последней надежды».

Дополнительные рекомендации и профилактика

Выясним причину, почему такие ошибки вообще возникают. Чаще всего это результат:

Внезапного отключения питания сервера или компьютера в момент записи в файл .1CD.
Сбоев в работе антивируса, который заблокировал файл во время транзакции.
Работы с базой по нестабильной локальной сети (для файлового варианта крайне критично наличие прямого подключения к диску).

Практический совет: Если база часто выдает ошибки СУБД в файловом варианте, а её размер превышает 2–4 Гб, настоятельно рекомендуем рассмотреть переход на клиент-серверный вариант (SQL). Даже бесплатная версия PostgreSQL обеспечит гораздо более высокую надежность транзакций и сохранность структуры таблиц по сравнению с форматом .1CD.

Также не забывайте про кэш конфигуратора. Иногда ошибка «Таблица не найдена» может быть ложной и вызвана «глюком» локального кэша. Перед началом серьезных работ по восстановлению структуры попробуйте очистить папки %LocalAppdata%\1C\1cv8 и %Appdata%\1C\1cv8 — это может сэкономить вам массу времени.

Разберем итог: мы научились идентифицировать битую таблицу через СтруктуруХраненияБазыДанных, удалять и восстанавливать объекты метаданных для «лечения» структуры и решать проблемы с дублями в регистрах сведений. Эти инструменты позволят вам восстановить работоспособность базы данных даже в самых сложных случаях.