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

← На главную

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

Анализ причин некорректного поведения динамических списков

Проанализируем механику работы динамических списков в управляемых формах. Когда пользователь вводит значение в стандартное поле «Поиск» (комбинация клавиш Ctrl+F), платформа 1С по умолчанию применяет механизм полнотекстового поиска (ППД). Если запись находится только после ручной модификации и сохранения объекта, это прямой признак того, что нарушена фоновая индексация базы либо рассинхронизированы ключи доступа RLS.

Выделим четыре основные причины проблемы:

Рассинхронизация или повреждение индекса полнотекстового поиска. При отключенных или зависших фоновых заданиях индексации новые и измененные объекты попадают в индекс только в момент ручной перезаписи.
Сбой в механизме ограничения прав на уровне записей (RLS). В конфигурациях на базе БСП (включая «1С:Бухгалтерию предприятия 3.0») используются специальные регистры ключей доступа. Если фоновое обновление прав заблокировано, динамический список исключает старые документы из выборки для пользователя.
Накопление поврежденных пользовательских настроек. Сохраненные варианты списков, отборов и колонок кэшируются в объекте ХранилищеСистемныхНастроек. Если структура списка была изменена или повреждена, старые отборы начинают искажать вывод строк.
Фрагментация индексов и устаревшая статистика СУБД. На стороне SQL-сервера динамический список формирует постраничные запросы с ограничением TOP. Устаревшая статистика заставляет оптимизатор строить неверные планы выполнения, что визуально выглядит как потеря строк.

Способ 1. Сброс пользовательских настроек списков и отчетов

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

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

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

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


ВыборкаПользователей = ПользователиИнформационнойБазы.ПолучитьПользователей();
КлючОбъектаНастройки = "Документ.РеализацияТоваровУслуг.Форма.ФормаСписка/ДинамическийСписок";

Для Каждого ТекПользователь Из ВыборкаПользователей Цикл
    ХранилищеСистемныхНастроек.Удалить(
        КлючОбъектаНастройки, 
        "", 
        ТекПользователь.Имя
    );
КонецЦикла;

Способ 2. Восстановление и перестроение индекса полнотекстового поиска

Когда поиск по строке не видит старые документы, в первую очередь выполним полное перестроение индекса полнотекстового поиска данных.

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

Способ 3. Обновление ключей доступа и прав RLS

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

Откроем Администрирование → Настройки пользователей и прав → Группы доступа.
Проверим состояние регламентных заданий: Обновление прав доступа (длинные) и Обновление прав доступа (срочные).
При наличии зависших заданий перезапустим процесс обновления прав или выполним принудительный пересчет прав доступа для проблемных объектов через меню обслуживания конфигурации.

Способ 4. Тестирование таблиц и обслуживание на стороне SQL-сервера

Для устранения проблем расхождения поведения между файловой базой и клиент-серверным режимом выполним регламентные процедуры обслуживания базы данных.

Запустим информационную базу в режиме Конфигуратор от имени администратора.
Перейдем в меню Администрирование → Тестирование и исправление....
Установим обязательные флаги: Реиндексация таблиц информационной базы и Пересчет итогов.
В блоке выбора действий при наличии ссылочной целостности укажем Очищать ссылки или Создавать объекты в зависимости от регламента предприятия и нажмем Выполнить.
На стороне MS SQL Server запустим план обслуживания (Maintenance Plan), включающий перестроение индексов (Rebuild Index) и обязательное обновление статистики (Update Statistics с параметром FULLSCAN) для оптимизации выборки динамических списков.

Практическая рекомендация: Если пользователям требуется выполнить строгий отбор по конкретному реквизиту (например, только по полю Организация или Контрагент), надежнее использовать явный отбор через меню Еще → Настроить список → Отбор вместо строки общего контекстного поиска. Это формирует прямой запрос с условием WHERE на уровне СУБД, исключая зависимость от состояния индекса ППД.