Как протестировать базу 1С на ошибки

Ошибки в информационной базе 1С проявляются по-разному: программа аварийно закрывается, документы не проводятся, отчёты показывают неверные данные, а при обращении к справочникам появляются сообщения «Ошибка формата потока» или «Ошибка СУБД». Причины — некорректное завершение работы, сбои питания, проблемы с диском или сетью, а также ошибки в самом коде конфигурации. В большинстве случаев базу можно вернуть в рабочее состояние штатными средствами.

У платформы 1С есть три основных инструмента диагностики: режим «Тестирование и исправление» в конфигураторе, утилита chdbfl для файловых баз и средства проверки на уровне СУБД для клиент-серверных вариантов. Каждый из них решает свой круг задач, и выбор зависит от типа базы и характера сбоя.

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

Какие ошибки бывают и как их распознать

Ошибки базы 1С условно делятся на три группы. Первая — физические повреждения файла базы данных: битые страницы, нарушенная внутренняя структура таблиц. Обычно они возникают после внезапного отключения питания, сбоев диска или обрыва сети при работе с файловой базой по сети. Признаки — база не открывается вовсе или падает при обращении к конкретным объектам.

Вторая группа — нарушения ссылочной целостности: документ ссылается на удалённый или несуществующий элемент справочника, в движениях регистров «потерянные» записи. Такое часто появляется после нештатного удаления объектов, обменов с ошибками или прямых манипуляций с данными. Проявляется как «Объект не найден» в отчётах и документах.

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

Обязательная подготовка: резервная копия

Перед любым тестированием создайте полную копию базы. Для файловой базы достаточно скопировать файл 1Cv8.1CD в другое место при условии, что все пользователи вышли из программы. Надёжнее — сделать выгрузку через конфигуратор: меню «Администрирование» → «Выгрузить информационную базу». Файл .dt позволяет восстановить базу даже при повреждённом исходном файле.

Для клиент-серверной базы используйте штатные средства СУБД (например, резервное копирование в MS SQL Server) или выгрузку .dt через конфигуратор. Убедитесь, что копия действительно создалась и файл открывается — проверьте его размер и, при возможности, загрузите копию в тестовую базу.

Проверка файловой базы утилитой chdbfl

Утилита chdbfl.exe входит в состав платформы и находится в каталоге bin установленной версии (например, C:\Program Files\1cv8\<номер версии>\bin\chdbfl.exe). Она проверяет физическую целостность файла 1Cv8.1CD на низком уровне — то, что недоступно конфигуратору.

Порядок работы простой: убедитесь, что все сеансы с базой закрыты, запустите chdbfl.exe, укажите путь к файлу 1Cv8.1CD, установите флажок «Исправлять обнаруженные ошибки» и нажмите «Выполнить». Утилита последовательно проверит таблицы и сообщит о найденных повреждениях.

Если ошибки найдены и исправлены, после chdbfl обязательно запустите «Тестирование и исправление» в конфигураторе: низкоуровневое восстановление может оставить несогласованные данные на уровне логики. Если утилита сообщает о неустранимых повреждениях значительной части таблиц — восстанавливайте базу из резервной копии, а не пытайтесь «вытащить» остатки вручную.

C:\Program Files\1cv8\<версия>\bin\chdbfl.exe  → указать файл 1Cv8.1CD → отметить «Исправлять обнаруженные ошибки» → Выполнить

Важно понимать ограничение: chdbfl работает только с файловым вариантом базы. Для базы на SQL Server, PostgreSQL или Oracle этот инструмент бесполезен — там физическую проверку выполняют средствами самой СУБД.

Тестирование и исправление в конфигураторе

Основной инструмент — режим «Тестирование и исправление» (ТиИ). Откройте базу в конфигураторе монопольно, перейдите в «Администрирование» → «Тестирование и исправление». В открывшемся окне выберите проверки и режим.

Доступны три группы проверок. «Реиндексация таблиц» перестраивает индексы — помогает при медленной работе и части ошибок доступа. «Проверка логической целостности» выявляет ошибки в данных и итогах. «Проверка ссылочной целостности» находит битые ссылки на несуществующие объекты. Для полной диагностики обычно отмечают все три пункта.

Режим «Тестирование» только показывает ошибки, ничего не меняя — начинайте с него, чтобы оценить масштаб проблемы. Режим «Тестирование и исправление» устраняет найденное. Для битых ссылок предусмотрены варианты: создать объекты-заглушки, очистить ссылки или удалить объект — выбирайте осознанно, потому что удаление может затронуть нужные документы.

1. 1
   Сделайте резервную копию и завершите все сеансы пользователей
2. 2
   Откройте конфигуратор: Администрирование → Тестирование и исправление
3. 3
   Отметьте реиндексацию, проверку логической и ссылочной целостности
4. 4
   Выберите режим «Тестирование» и запустите — зафиксируйте список ошибок
5. 5
   Переключитесь в режим «Тестирование и исправление» и выполните повторно
6. 6
   После завершения проверьте работоспособность базы в пользовательском режиме

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

Особенности клиент-серверных баз

Если база работает на сервере СУБД, файл 1Cv8.1CD отсутствует, и chdbfl не применяется. Физическую целостность проверяют средствами СУБД: например, в MS SQL Server — командой DBCC CHECKDB для соответствующей базы данных. Эту операцию должен выполнять администратор СУБД, поскольку проверка влияет на производительность сервера.

Поверх проверки СУБД всё равно запускается ТиИ в конфигураторе — он устраняет ошибки на уровне прикладных данных: битые ссылки, расхождения итогов, логические несогласованности, которые СУБД не видит. Эти два уровня дополняют друг друга, а не заменяют.

Проверка результата и типичные ошибки

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

Если ошибки остались, посмотрите технологический журнал и журнал регистрации — они покажут, в каком объекте продолжает возникать сбой. Иногда проблема не в базе, а в кэше метаданных на клиенте: очистка кэша (удаление папки базы из каталога appdata пользователя) решает часть «фантомных» ошибок формата потока.

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

FAQ