1С пишет «запрос не выполнен»: причины и пошаговое решение

Сообщение «запрос не выполнен» в 1С появляется, когда платформа не смогла выполнить обращение к базе данных: к встроенному механизму файловой базы или к серверу СУБД (MS SQL, PostgreSQL, Oracle, IBM Db2). Сама по себе фраза малоинформативна — это лишь верхний уровень ошибки. Настоящая причина всегда находится в деталях сообщения, которые следуют после неё, или в технологическом журнале.

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

Ниже разобраны типовые причины: синтаксические ошибки в тексте запроса, нехватка прав, блокировки и дедлоки, проблемы с сервером СУБД, повреждение базы и ошибки в коде доработок. Для каждого случая приведены признаки, способ проверки и безопасные действия.

Где искать настоящую причину ошибки

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

Второй источник — технологический журнал (ТЖ). Он включается через файл logcfg.xml в каталоге conf каталога установки 1С. Для анализа ошибок запросов полезны события DBMSSQL, DBPOSTGRS, EXCP, TLOCK, TDEADLOCK. Журнал покажет точный текст запроса, контекст и код ошибки СУБД.

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

Ошибки в тексте запроса

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

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

Запросы к виртуальным таблицам

Частный случай — обращение к виртуальным таблицам регистров (Остатки, Обороты, СрезПоследних) с параметрами, которые не заданы или заданы неверным типом. Например, параметр периода передан как строка вместо даты. Платформа в этом случае возвращает ошибку выполнения запроса с указанием на несоответствие типов. Проверьте типы всех параметров и отборов.

Недостаток прав доступа

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

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

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

Блокировки и взаимоблокировки

Если в деталях ошибки встречаются слова «lock timeout», «deadlock», «превышено время ожидания блокировки», «конфликт блокировок при выполнении транзакции» — запрос не выполнен из-за конкуренции за данные. Один сеанс держит блокировку на записи, второй ждёт и по таймауту завершается с ошибкой.

Типовые источники проблемы: длительные транзакции в доработках (проведение больших документов в цикле с обращением к тем же регистрам), массовая загрузка данных в рабочее время, регламентные задания, пересекающиеся с работой пользователей, отсутствие нужных индексов на СУБД, из-за чего блокируется избыточный объём данных.

Что делать: повторите операцию — иногда это разовый конфликт. Если повторяется систематически, включите в ТЖ события TLOCK и TDEADLOCK, найдите взаимоблокирующие запросы и оптимизируйте код: сокращайте длину транзакций, устанавливайте управляемые блокировки в правильном порядке, выносите массовые операции в нерабочее время.

Проблемы на стороне сервера СУБД

В клиент-серверном варианте запрос может не выполняться из-за состояния самой СУБД: переполнен журнал транзакций, закончилось место на диске, база переведена в состояние восстановления, служба остановлена, нарушена сетевая связность между сервером 1С и сервером СУБД.

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

Для MS SQL типичная ситуация — переполнение журнала транзакций при модели восстановления Full без регулярного резервного копирования журнала. Для PostgreSQL — исчерпание места из-за накопленных WAL-файлов. В обоих случаях сначала обеспечьте место и корректную настройку резервного копирования, и только потом анализируйте прикладной уровень.

Повреждение базы данных

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

Для файловой базы используйте утилиту chdbfl.exe из каталога bin установки 1С — она проверяет физическую целостность файла 1Cv8.1CD. Затем выполните тестирование и исправление через конфигуратор (Администрирование → Тестирование и исправление) с проверкой логической и референциальной целостности.

Для клиент-серверной базы используйте штатные средства СУБД: для MS SQL — проверку целостности средствами DBCC, для PostgreSQL — анализ журналов и при необходимости восстановление из резервной копии. Перед любыми исправляющими операциями сделайте резервную копию в текущем состоянии.

1. 1
   Остановите работу пользователей с базой и зафиксируйте текст ошибок
2. 2
   Сделайте копию базы в текущем состоянии до любых исправлений
3. 3
   Для файловой базы прогоните chdbfl.exe, затем тестирование и исправление в конфигураторе
4. 4
   Для клиент-серверной базы проверьте целостность средствами СУБД
5. 5
   Выполните пробную операцию, вызывавшую ошибку, и проверьте журнал регистрации
6. 6
   Если целостность не восстановлена — восстанавливайте базу из последней рабочей резервной копии

Ошибки после обновления и в доработках

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

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

Как проверить, что проблема решена

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

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

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

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

Повторное выполнение операции

Норма

Операция завершается без ошибок у всех затронутых пользователей

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

Ошибка повторяется или появляется у части пользователей

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

Норма

Нет новых записей с уровнем «Ошибка» по проблемной операции

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

Ошибки продолжают фиксироваться

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

Норма

Запросы выполняются, событий EXCP и TDEADLOCK нет

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

Исключения и взаимоблокировки продолжают записываться

Данные

Норма

Отчёты и итоги по затронутым регистрам сходятся с ожидаемыми

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

Расхождения в итогах, «битые» ссылки в документах

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

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

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

Ошибка возникает периодически и пропадает сама. Это опасно?

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

Можно ли исправить ошибку, просто переустановив платформу 1С?

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

Что делать, если ошибка возникает при обновлении конфигурации?

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

Как отличить проблему с СУБД от ошибки в запросе?

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

Опасно ли запускать «Тестирование и исправление» на рабочей базе?

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