Слишком сложный поисковый запрос 1с ошибка

Обновлено: 30.01.2023

У меня есть восемь таблиц, которые содержат информацию об изменениях, вносимых в приложения по всей компании. Я только хочу запросить и объединить строки для подмножества более 200 приложений. Для этого я запрашиваю каждую таблицу по коду приложения (AAA, BBB и т. Д.) И хочу объединить результаты. Когда я использую более 5 кодов приложения, я получаю ошибку «Запрос к комплексу».

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

Я хотел бы иметь возможность запрашивать все 200+ кодов приложений одновременно и более эффективно, чем вводить одну и ту же строку 8 раз для каждого кода.

3 ответа

Более простой подход мог бы заключаться в том, что union данные таблицы перед применяют критерии выбора, поэтому вам нужно указывать критерии только в одном месте, например:

Если вы не используете подстановочные операторы в рамках критериев для like , вы можете альтернативно использовать in и предоставить список кодов приложений:

Кроме того, вы можете создать таблицу, содержащую все коды приложений, которые вы хотите вернуть (в следующем примере я назвал такую таблицу ApplicationCodes , содержащую одно поле с именем Code ), а затем использовать простое объединение для неявного применения фильтрации, например:

Я бы порекомендовал вам создать таблицу, в которой есть все приложения, тогда вы могли бы сделать всего 8 запросов

Если вам это не нравится, вы можете попробовать предложение IN

Имена таблиц, которые содержат даты или порядковые номера и одни и те же поля, обычно должны сочетаться с именем таблицы в качестве дополнительного свойства.

Создайте таблицу (например, ApplicationChanges) с полями объединенных таблиц и добавьте дополнительное поле ChangedAt , которое будет содержать старое имя таблицы. Возможно, старые таблицы содержат поле даты, которое показывает дату ChangedAt, тогда вы можете опустить имя таблицы и запрос, какие даты принадлежат этой таблице.

Затем используйте запрос @LeeMacs для заполнения новой таблицы:

Если вам нужна старая структура данных, создайте запросы для каждой предыдущей таблицы с критерием ChangedAt. Например. Таблица [2019-07-A July 5 to 7]

Алексей Чужов

Возьмите др клиентов,вычтите из этих дат сутки.Затем можно например передать в переменные ДеньВчерРожд=день(ДатаРождМинусОдин);
МесяцВчерРожд=месяц(датаРождМинусОдин);
У вас получиться номер месяца вчерашнего дня рождения и дюномер дня вчерашнего др.А затем сравните их с номером дня и номером месяца текущей даты.Вообщем если не понятно или еще не сделали пишите,не мложно это.Единственный шаткий момент это високосные года.

Где именно хотите получить — в запросе, в СКД, в отчете?
Вообще, чем не устраивает задать дату рождения между:
конечная дата -конец дня текущей даты,
начальная дата — начало дня текущей даты — 24 часа.
В отбор попадут нужные клиенты.
Или у вас дата разбита — отдельно день, отдельно месяц, отдельно год?

Юрий, СКД. Дата разбита: отдельно День, Месяц. И когда задала Дату рождения Между (ДеньГода) — получила. что-то непонятное.

Вот как—то так: ДОБАВИТЬКДАТЕ(ДОБАВИТЬКДАТЕ(ДОБАВИТЬКДАТЕ(ДАТАВРЕМЯ(1, 1, 1), ГОД, 1984 — 1), МЕСЯЦ, 12 — 1), ДЕНЬ, 31 — 1) КАК Поле1 . Только вместо цифр года, месяца и дня подставить свои данные из запроса. Суть, берем дату 01.01.0001 и прибавляем день месяц и год. Если год не нужен, его можно опустить. Ну, тем более, имея уже собранную дату, вроде бы не сложно придумать нужное сравнение.

Дмитрий Сметанин запись закреплена

Необходимо создать обработку позволяющую загрузить содержимое файла Excel (в ячейках примитивные типы: строка, число) с любым количеством колонок и строк в таблицу значений на форму обработки.
Таблицу значений на форме нужно создавать программно.
В первой строке файла будут содержатся названия колонок, названия колонок в таблице на форме должны им соответствовать.
Пустые ячейки в таблице на форме нужно выделить красным цветом.

Здарова. Я сам когда-то только начинал работать с 1С. И тоже начинал с экселя. Я бы помог, но времени совсем щас нет. У меня осталась обработка на которой я тренировался. Там и загрузка написана и выгрузка. Может поможет.

Читайте также:

• Как связаны объекты конфигурации и объекты базы данных 1с
• Программа в топе как работает
• Как прошить asus zc500tg
• Как выйти в интернет без браузера на андроид
• Как в фотошопе сделать 3д обложку

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

ВЫБРАТЬ

       ЗначенияСвойствОбъектов.Объект КАК Объект,

       ЗначенияСвойствОбъектов.Свойство КАК Свойство,

       ВЫБОР

           КОГДА ЗначенияСвойствОбъектов.Значение.Код = 211

                   ИЛИ ЗначенияСвойствОбъектов.Значение.Код = 212

               ТОГДА «Ликероводочные изделия в т.ч.:»

           ИНАЧЕ ВЫБОР

                   КОГДА ЗначенияСвойствОбъектов.Значение.Код = 250

                           ИЛИ ЗначенияСвойствОбъектов.Значение.Код = 251

                       ТОГДА «Напитки винные в т.ч.:»

                   ИНАЧЕ ВЫБОР

                           КОГДА ЗначенияСвойствОбъектов.Значение.Код = 400

                                   ИЛИ ЗначенияСвойствОбъектов.Значение.Код = 410

                               ТОГДА «Вина в т.ч.:»

                           ИНАЧЕ ЗначенияСвойствОбъектов.Значение

                       КОНЕЦ

               КОНЕЦ

       КОНЕЦ КАК Значение1,

       ЗначенияСвойствОбъектов.Значение КАК Значение

   ИЗ

       РегистрСведений.ЗначенияСвойствОбъектов КАК ЗначенияСвойствОбъектов

   ГДЕ

       ЗначенияСвойствОбъектов.Свойство = &КОДПр

Причем если выкинуть хоть какое-нибудь условие (одно) то все работает.

Другие статьи по оптимизации 1С:

«Оптимизация 1С – Проблемы производительности»

«Как ускорить 1С – Многопоточная обработка данных»

«Анализ запросов с помощью SQL Profiler»

Часто при внедрении программ «1С: Предприятие 8» возникают ситуации, в которых простые запросы работают достаточно медленно.

Покажем варианты оптимизации таких запросов.

Для примера рассмотрим запрос из реального проекта (в базе клиента он выполнялся более 6 секунд)

C первого взгляда все хорошо, но опытный программист увидит неоптимальный код в запросе.

Источником проблем выступает параметр виртуальной таблицы, а точнее – обращение через «две точки» в фильтре.

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

Самым первым вариантом решения в голову приходит использовать конструкцию языка запросов «ВЫРАЗИТЬ», чтобы привести поле «Документ» к некоторому определенному типу. Это позволит избежать соединений с лишними таблицами.

Но по ряду ограничений данный вариант не подходит:

1. Нам нужны все документы, содержащиеся в составном типе. Таковы условия постановки задачи. Получается, что необходимо фильтровать все типы документов, входящие в составной тип.
2. Даже если бы не было предыдущего ограничения, то обращение через «две точки» никуда не делось.
3. Если бы можно было использовать «ВЫРАЗИТЬ», то это не спасало бы ситуацию: в параметрах виртуальной таблицы «ВЫРАЗИТЬ» не дает прироста производительности.

Оптимизация

Исходя из вышесказанного, прежде всего необходимо избавиться от обращения через «две точки» и при этом не испортить саму логику нашего запроса.
Из нескольких способов решения задачи предлагаем два следующих варианта:

Вариант 1

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

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

Что мы видим? Этот запрос начинает работать моментально.

И это, к сожалению, единственный положительный момент, минусов наблюдается существенно больше.

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

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

Поэтому рассмотрим второй вариант.

Вариант 2

Можно попробовать изменить запрос так, чтобы фильтр по полю «Документ» накладывался примерно следующим образом:

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

В нашем составном типе определены 5 документов, причем искомый реквизит «Контрагент» присутствует только в документах:

• ПоступлениеБезналичныхДенежныхСредств
• СписаниеБезналичныхДенежныхСредств
• РасходныйКассовыйОрдер
• ОперацияПоПлатежнойКарте

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

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

После проведенной оптимизации запрос стал выполняться менее одной секунды!

Да, при этом он стал сложнее, но нет необходимости в изменении структуры метаданных, как в первом варианте.

Резюме

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

Рекомендуем оптимизировать запросы посредством изменения текста самого запроса.

Бурмистров Андрей

PDF-версия статьи для участников группы ВКонтакте

Мы ведем группу ВКонтакте – http://vk.com/kursypo1c.

Если Вы еще не вступили в группу – сделайте это сейчас и в блоке ниже (на этой странице) появятся ссылка на скачивание материалов.

Если Вы уже участник группы – нужно просто повторно авторизоваться в ВКонтакте, чтобы скрипт Вас узнал. В случае проблем решение стандартное: очистить кеш браузера или подписаться через другой браузер.