Где найти запрос динамического списка формы 1С
Как получить текст запроса динамического списка через code_read.form_query и отличить исполняемый запрос от переопределённого в BSL или автоматически построенного.
В форме есть динамический список, но поиск по BSL не находит его запрос. Причина может быть простой: текст сохранён в описании формы. Бывает и обратная ситуация — запрос в XML есть, но модуль формы присваивает другой, поэтому анализ сохранённого текста уводит в сторону.
С v2.34.0 в Расширенной и Профессиональной редакциях MCP-1C есть действие form_query инструмента code_read. Оно читает запросы динамических списков из выгрузки и возвращает статус каждого списка. Это отдельная задача от form_structure, которое перечисляет списки без их текста. Параметры опубликованы в описании code_read, выпуск — в истории изменений.
В статье: вызов, пять статусов, разбор переопределения, проверка формы.
Запросите форму по техническому имени
Серверу нужна выгрузка, подключённая через --dump. В аргументах code_read обязательны вид и имя объекта; form_name ограничивает запрос одной формой. Пример для условного документа:
{
"action": "form_query",
"object_type": "Document",
"object_name": "ЗаказКлиента",
"form_name": "ФормаСписка"
}
Если не задать form_name, возвращаются списки всех форм объекта. Для общей формы используйте object_type: "CommonForm", а в object_name передайте имя самой формы. Технические имена уточняйте через метаданные, особенно если пользовательский заголовок отличается от имени объекта.
Ответ связывает каждый список с именем его реквизита. Если на форме несколько списков, эта привязка помогает определить, к какой таблице относится найденный запрос.
Прочитайте статус до анализа SQL-подобного текста
| Статус | Как его трактовать |
|---|---|
executable |
По доступным исходникам запрос включён, распознанного переопределения не найдено |
overridden_in_bsl |
Модуль формы присваивает запрос; сохранённый текст не является исполняемым |
not_used |
Произвольный запрос выключен; используется построение по основной таблице |
auto |
Произвольный запрос выключен и текст не записан |
not_checked |
Проверка не дала ответа; это неизвестность |
Для not_used сохранённый текст может выглядеть убедительно, но оптимизировать его как работающий запрос бессмысленно. Для auto отсутствие текста нормально: платформа формирует запрос сама. А not_checked нельзя превращать в вывод «переопределения нет».
Статусы относятся к статическому разбору исходников. Они помогают выбрать следующий файл для чтения, но не дают время выполнения списка и не показывают его фактическую выборку. Читайте поле explanation: общие модули просматриваются только на один уровень, дальнейшая цепочка передачи списка и сборка текста во время работы могут остаться невидимыми. Даже executable не доказывает, какой запрос фактически выполнился в конкретном сеансе.
Если запрос переопределяется в BSL
Найдите присваивание текста в модуле формы и условия, при которых оно выполняется. Проверьте, зависит ли запрос от параметров открытия, функциональных опций или состояния пользователя. Один фрагмент XML не описывает все эти варианты.
Попросите агента сначала показать источник запроса и связанные условия, а затем предлагать изменение. Сохраните имя реквизита списка и нужную ветку кода в задаче. Это снижает риск исправить похожий список другой формы или текст, который уже не используется.
После выделения фактического запроса его можно проверить по метаданным через check_query. Производительность требует дополнительной проверки на подходящих данных; отсутствие статических замечаний не означает быстрый список.
Что проверить после правки
Откройте форму в тестовой базе, дождитесь получения данных и сравните строки с ожидаемым набором. Проверьте отбор, сортировку и переход к следующей порции строк. Если запрос меняется при открытии с параметрами, пройдите каждый затронутый вариант.
Для списка с ограничением доступа проверьте соответствующую роль и данные за пределами разрешённой области. Для исправления скорости измерьте тот же пользовательский сценарий до и после изменения в сопоставимых условиях.
form_query помогает ответить на первый важный вопрос — какой текст вообще нужно разбирать. Схема формы даёт соседний контекст, а работающий клиент подтверждает поведение списка.