Ищем ошибки в 1С 8.3: база, конфигурация, код и скорость

Протестировать 1С 8.3 на ошибки — это не одна кнопка, а четыре разных проверки: таблицы базы (Администрирование → Тестирование и исправление в Конфигураторе), код конфигурации (Конфигурация → Проверка конфигурации), журнал регистрации и, если база тормозит, технологический журнал. Частое заблуждение — запустить «Тестирование и исправление» и ждать, что оно найдёт ошибку в отчёте или неверную проводку. Оно лечит только физику базы: индексы, битые ссылки, итоги регистров.

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

Подготовка к проверке: копия базы и монопольный режим

Любая проверка, которая что-то исправляет, меняет данные. Поэтому порядок такой:

1. 🗂 Сделайте выгрузку: в Конфигураторе Администрирование → Выгрузить информационную базу, файл .dt. Для файловой базы дополнительно скопируйте каталог с файлом 1Cv8.1CD.
2. 👥 Попросите всех выйти из программы. «Тестирование и исправление» требует монопольного доступа: пока в базе есть хотя бы один сеанс, запуск не пройдёт.
3. 🖥 Для клиент-серверной базы проверьте сеансы в консоли администрирования кластера и запретите новые подключения на время работ (свойство базы «Блокировка начала сеансов включена»).
4. 💾 Для базы на MS SQL или PostgreSQL сделайте ещё и бэкап средствами СУБД. Выгрузка .dt на большой базе идёт долго и не заменяет полноценную копию.

Если база большая, сначала прогоните тест на копии. Так вы узнаете и время работы, и масштаб проблем, не трогая рабочий контур.

Тестирование и исправление информационной базы 1С 8.3

Откройте базу в режиме Конфигуратор и выберите Администрирование → Тестирование и исправление.... Откроется окно с набором галочек.

Режим и реакция на найденные ошибки

Внизу окна выбирается режим: «Тестирование и исправление» или «Только тестирование». Первый прогон всегда делайте в режиме «Только тестирование». Он покажет список проблем и ничего не изменит.

Дальше важны две настройки:

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

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

Результат появится в окне сообщений Конфигуратора. Сохраните его в файл: по тексту потом видно, какие таблицы и объекты пострадали.

Файловая база не открывается: утилита chdbfl.exe

Если файловая база падает уже при запуске и до Конфигуратора не дойти, используйте утилиту chdbfl.exe. Она лежит в каталоге bin установленной платформы, например C:\Program Files\1cv8\8.3.xx.xxxx\bin\chdbfl.exe.

1. Убедитесь, что базу никто не открыл.
2. Запустите chdbfl.exe, укажите путь к файлу 1Cv8.1CD.
3. Сначала нажмите «Выполнить» без галочки «Исправлять обнаруженные ошибки».
4. Если ошибки есть — сделайте копию файла и повторите с галочкой.

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

Запуск из командной строки

Для регламентной проверки по расписанию тестирование запускают без интерфейса:

"C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe" DESIGNER /F"D:\Bases\Buh" /N"Администратор" /P"пароль" /IBCheckAndRepair -LogAndRefsIntegrity -TestOnly /Out"D:\Logs\check.txt"

Ключ -TestOnly оставляет режим «только тестирование». Уберите его, и платформа начнёт исправлять. Для серверной базы вместо /F указывают /S"сервер\имя_базы".

База на SQL: проверка средствами СУБД

«Тестирование и исправление» не видит повреждения страниц данных на уровне MS SQL. Если в журнале СУБД есть ошибки чтения или 1С пишет об ошибке СУБД, администратор базы запускает DBCC CHECKDB для базы данных 1С. Делается это в часы, когда пользователей нет: проверка нагружает диск.

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

Ошибки в самой конфигурации — синтаксис, ссылки на удалённые реквизиты, вызовы недоступных на клиенте методов — ищут в Конфигураторе: Конфигурация → Проверка конфигурации....

Что стоит включить:

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

Результат — список с указанием модуля и строки. Двойной щелчок открывает модуль на месте ошибки.

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

Журнал регистрации: где база сама записала ошибку

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

Как открыть:

• в пользовательском режиме: Все функции → Стандартные → Журнал регистрации (команду «Все функции» включают в Сервис и настройки → Параметры);
• в Конфигураторе: Администрирование → Журнал регистрации.

Настройте отбор:

1. 📅 Интервал — время, когда произошёл сбой, с запасом в 10–15 минут.
2. 🔴 Уровень — «Ошибка» (при необходимости добавьте «Предупреждение»).
3. 👤 Пользователь — тот, у кого случилась проблема.

В колонке «Комментарий» лежит полный текст ошибки, часто с модулем и номером строки, например {Документ.РеализацияТоваровУслуг.МодульОбъекта(512)}. Это готовая точка для отладчика.

Если журнал пуст, проверьте уровень логирования: Администрирование → Настройка журнала регистрации в Конфигураторе. Там же выставляется, как часто журнал делится на файлы.

Отладчик: как найти логическую ошибку

Если ошибка повторяется — при проведении определённого документа или формировании отчёта, — поймайте её отладчиком.

1. В Конфигураторе откройте модуль из текста ошибки и поставьте точку останова на нужной строке клавишей F9.
2. Запустите отладку: Отладка → Начать отладку → Тонкий клиент (или F5).
3. Повторите действие пользователя. Выполнение остановится на точке.
4. Шагайте по коду: F10 — шагнуть через процедуру, F11 — шагнуть внутрь.
5. Смотрите значения переменных в табло или через Shift+F9 («Вычислить выражение»).

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

Отладка на сервере 1С

Для клиент-серверной базы серверный код отлаживается, только если отладка включена на сервере. Агент сервера должен быть запущен с ключом -debug, это прописывается в параметрах службы. Включение требует перезапуска службы агента.

Не держите отладку на рабочем сервере постоянно: точка останова в общем модуле остановит не только ваш сеанс. Для отладки лучше развернуть копию базы на тестовом сервере.

Автоматизированное тестирование 1С: xUnit и сценарии

Ручная проверка после каждого обновления отнимает часы. Автотесты делают то же самое за минуты и одинаково каждый раз.

Vanessa ADD и Vanessa Automation — открытые проекты, распространяются как внешние обработки. Оба опираются на механизм тестирования платформы: один клиент запускается как менеджер тестирования (ключ /TESTMANAGER), второй — как тестируемый клиент (ключ /TESTCLIENT).

С чего начать без большой команды:

1. Выберите 10–15 ключевых операций: поступление, реализация, оплата, закрытие месяца , расчёт зарплаты.
2. Запишите по ним сценарии на копии базы с эталонными данными.
3. После каждого обновления или доработки прогоняйте набор и сравнивайте результат с эталоном — суммы документов, остатки, движения регистров.

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

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

Медленная работа — тоже ошибка, только без окна с сообщением. Инструментов два.

Замер производительности

В Конфигураторе во время отладки включите Отладка → Замер производительности. Выполните медленную операцию и остановите замер. Платформа покажет, сколько раз выполнилась каждая строка кода и какой процент времени она заняла.

Обычно наверху оказываются запросы в цикле или обращения через точку к реквизитам ссылок. Их и переписывают.

Технологический журнал

Технологический журнал пишет события на уровне платформы: исключения, вызовы СУБД, управляемые блокировки, взаимоблокировки. Его включают файлом logcfg.xml в каталоге conf платформы. Пример настройки для поиска исключений и проблем с блокировками:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1C_TJ" history="24">
    <event><eq property="name" value="EXCP"/></event>
    <event><eq property="name" value="TTIMEOUT"/></event>
    <event><eq property="name" value="TDEADLOCK"/></event>
    <property name="all"/>
  </log>
</config>

• 🧨 EXCP — исключения, в том числе те, что пользователь не увидел.
• ⏳ TTIMEOUT — превышено время ожидания блокировки: «пользователи ждут друг друга».
• 🔒 TDEADLOCK — взаимоблокировка, одна из транзакций откатывается.

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

Разбирать логи вручную неудобно. Обычно их фильтруют поиском по имени события или загружают в анализаторы — от самописных скриптов до готовых обработок разбора ТЖ.

Частые ошибки при тестировании базы

• ❌ Сразу ставят все галочки, включая реструктуризацию. На большой базе это часы работы, а реструктуризация нужна редко. Начните с логической и ссылочной целостности.
• ❌ Запускают исправление без «Только тестирования». Вы не узнаете, что именно платформа изменила.
• ❌ Прерывают тестирование «потому что долго». Прерванная реструктуризация может оставить базу в худшем состоянии, чем до начала. Запускайте с запасом времени.
• ❌ Ищут ошибку отчёта тестированием базы. Если документы и проводки неверные, «Тестирование и исправление» их не поправит — это вопрос учёта или кода.
• ❌ Оставляют технологический журнал включённым. Диск заканчивается, и сервер падает уже из-за нехватки места.

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