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

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

Для файловых баз основные инструменты — «Тестирование и исправление» в конфигураторе и утилита chdbfl.exe. Для клиент-серверных баз добавляется проверка на уровне СУБД. Логические ошибки в учёте ищут штатными отчётами, обработками контроля и журналом регистрации. Ниже разобран каждый способ с порядком действий и ограничениями.

Перед любыми проверками, особенно с включённым режимом исправления, обязательно сделайте резервную копию. Для файловой базы достаточно скопировать файл 1Cv8.1CD при закрытой программе, для серверной — выгрузить dt через конфигуратор или сделать бэкап средствами СУБД.

Как понять, какой тип ошибки у базы

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

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

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

Резервная копия перед проверкой

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

Для файловой базы завершите все сеансы, убедитесь, что никто не работает, и скопируйте файл 1Cv8.1CD в отдельную папку. Для серверной базы используйте выгрузку в dt (Администрирование → Выгрузить информационную базу) или штатный бэкап SQL Server / PostgreSQL. Проверьте, что копия открывается, — только после этого приступайте к проверкам.

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

Основной штатный инструмент находится в конфигураторе: меню «Администрирование» → «Тестирование и исправление». Запуск возможен только в монопольном режиме — все пользователи должны выйти из базы.

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

Порядок работы: сначала запустите нужные проверки в режиме «Только тестирование» и изучите протокол. Затем, поняв масштаб проблем, повторите с режимом «Тестирование и исправление», выбрав вариант обработки ошибок (например, для битых ссылок — «Не изменять», «Создавать объекты» или «Очищать ссылки»).

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

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

Когда файловая база не открывается совсем или конфигуратор падает при тестировании, используется утилита chdbfl.exe из каталога bin установленной платформы (папка конкретной версии). Она проверяет физическую целостность файла 1Cv8.1CD на уровне ниже, чем конфигуратор, и часто справляется с повреждениями, недоступными штатному тестированию.

Запустите chdbfl.exe, укажите путь к файлу базы, отметьте «Исправлять обнаруженные ошибки» и нажмите «Выполнить». Утилита работает только с файлом, к которому нет открытых подключений. После её завершения откройте базу в конфигураторе и дополнительно прогоните «Тестирование и исправление» — физическое восстановление не гарантирует логическую согласованность данных.

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

Журнал регистрации и поиск причин сбоев

Журнал регистрации (Конфигуратор → Администрирование → Журнал регистрации, либо в режиме предприятия через стандартную функцию) фиксирует ошибки, предупреждения и действия пользователей. Это первый источник ответа на вопрос «что именно сломалось и когда».

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

Если ошибки появляются регулярно в одно и то же время, проверьте расписание регламентных заданий — частая причина «плавающих» сбоев. Для серверных баз дополнительно смотрите технологический журнал и логи СУБД.

Проверка конфигурации и кода

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

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

Для глубокого анализа доработок применяют специализированные средства проверки кода по стандартам разработки (например, расширения для EDT). Они находят потенциальные дефекты: запросы в циклах, небезопасное использование транзакций, утечки производительности. Это особенно актуально перед обновлением типовой конфигурации с доработками.

Контроль данных в режиме предприятия

Физическая целостность базы не гарантирует правильность учёта. Для логического контроля используйте штатные механизмы прикладного решения. В типовых конфигурациях есть «Экспресс-проверка ведения учёта», которая проверяет выполнение контрольных соотношений: закрытие счетов, остатки по регистрам, корректность НДС и другие правила конкретной конфигурации.

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

Контрольные точки

Как проверить результат

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

Норма

База открывается, документы и отчёты доступны без ошибок

Тревожный признак

Ошибки формата потока, аварийное завершение

Ссылочная целостность

Норма

Нет записей «Объект не найден» в документах и отчётах

Тревожный признак

Битые ссылки в движениях и табличных частях

Итоги отчётов

Норма

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

Тревожный признак

Расхождения итогов, отрицательные остатки

Журнал регистрации

Норма

Нет повторяющихся ошибок после исправления

Тревожный признак

Те же ошибки появляются снова

Типичные ошибки при самостоятельной проверке

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

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

Когда нужен специалист

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

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

Частые вопросы

Можно ли запускать тестирование и исправление, пока пользователи работают?

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

Чем отличается chdbfl от тестирования и исправления?

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

Как часто нужно проверять базу на ошибки?

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

Что делать, если после исправления пропали документы?

Немедленно прекратите работу в базе, чтобы не перезаписать данные. Восстановите резервную копию в отдельный каталог, сравните её с текущей базой и перенесите недостающие документы — вручную или через выгрузку-загрузку. Если копии нет, восстановление возможно только частично, по данным связанных систем или бумажным первичным документам.

Поможет ли переустановка платформы 1С при ошибках базы?

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