gifts2017

Помощник для написания запроса в тонком клиенте

Опубликовал Николай Больсунов (boln) в раздел Программирование - Инструментарий

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

Помощник для написания запроса в тонком клиенте

 

Краткое описание работы

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

Предлагаемый инструмент призван оказать помощь при ручном составлении запроса. Ему, конечно, очень далеко до Конструктора запроса 1С. По принципу действия он похож на Конструктор произвольного выражения (вспомогательный инструмент Конструктора запроса), а также на инструмент "шаблонов": текст запроса пишется путем "перетаскивания" мышью элементов из заранее полученных списков полей таблиц базы и Словаря конструкций языка запросов в поле текста запроса.

Таким образом, этот инструмент можно охарактеризовать лишь как Помощник (Mate)  при ручном написании запроса.

Помощник представляет собой подчиненную экранную форму Консоли запросов, которая открывается из контекстного меню поля текста запроса Консоли (пункт меню Открыть "Пишем запрос в тонком клиенте").

С работой Консоли запросов можно ознакомиться здесь.

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

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

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

Таблицы, для которых получены описания полей, могут быть помещены в список Выбранные (двойным щелчком или по кнопке Выбрать). Им можно назначить псевдонимы (по кнопке Назначить псевдоним, расположенной над списком Выбранные, открывается форма Задать псевдоним) - и поля таблиц будут "перетаскиваться" в поле текста запроса с  этими псевдонимами.

Когда таблицы для запроса выбраны, можно начать составлять текст запроса. Конструкции языка запросов можно "перетаскивать" мышью из списка конструкций на закладке Конструкции, в котором можно установить отбор по начальной букве. Обращения к таблицам и полям перетаскиваются из списка Выбранные на закладке Таблицы; при этом доступно разыменование ссылочных полей по всем уровням, как в Конструкторе запроса.

(Понятно, что любые элементы текста запроса можно также вводить и редактировать вручную с клавиатуры).

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

По окончании написания запроса надо нажать кнопку OK - форма Помощника закроется, и запрос будет передан в Консоль запросов.

Контроль синтаксической правильности текста запроса полностью лежит на программисте.

 

Быстродействие

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

Для УТ это время вполне приемлемо - например, получение описаний нескольких помеченных таблиц регистров накопления (в файловом режиме) происходит за 5-10 секунд.

Для БП и ЗУП это время может составлять уже 15-30 секунд.

Для УПП использовать Помощник нецелесообразно - составление описания даже одной виртуальной таблицы может занимать несколько минут в клиент-серверном режиме; в файловом режиме это время может доходить до нескольких десятков минут (вспомним, что при этом составляются также описания всех ссылочных таблиц по всем уровням).

Но все полученные описания сохраняются до закрытия основной формы Консоли запросов - т.е. в одном сеансе работы с Консолью форму Помощника можно открывать и закрывать неограниченное число раз без потери полученных описаний.

 

Пример работы

Пример работы с Помощником приводится в прилагаемом видеоролике - см. файл Video_Query_Mate.rar.

 

Ограничения

  1. Помощник работает только при варианте встроенного языка конфигурации Русский.
  2. Нет возможности получать описания временных таблиц пакетного запроса, все обращения к таким таблицам надо писать вручную.
  3. В текущей версии не поддерживается получение описаний таблиц изменения данных, таблиц бухрегистра без корреспонденции и таблиц перерасчетов.

 

 

Скачать файлы

Наименование Файл Версия Размер
Обработка Консоль запросов с Помощником 206
.epf 72,94Kb
10.07.13
206
.epf 72,94Kb Бесплатно
Видеоролик с примером работы 48
.rar 1,73Mb
10.07.13
48
.rar 1,73Mb Бесплатно

См. также

Подписаться Добавить вознаграждение

Комментарии

0. Николай Больсунов (boln) 01.04.11 16:39
Обработка дает возможность писать в тонком клиенте текст запроса не вручную, а перетаскивая имена таблиц, полей и конструкции языка запроса мышью.

Перейти к публикации

1. Сергей Ожерельев (Поручик) 01.04.11 16:39
(0)
Описания метаданных можно сохранять и считывать в ХранилищеОбщихНастроек.Сохранить(Объект, Настройка, Значение);
2. Сергей Ожерельев (Поручик) 01.04.11 16:42
Настройки формы тоже можно сохранять. А так полезная фича.
3. Николай Больсунов (boln) 01.04.11 19:45
(2) Спасибо, насчет Хранилища - надо попробовать.

Я пытался на стороне сервера (в файловом режиме) при помощи ЗначениеВФайл() сохранять дерево в файл. Для УПП процесс сохранения-восстановления - десятки минут (все таблицы), файл серилизации получался чуть не 10 Мб. Так что всего можно и здесь ожидать...

Вся беда, ИМХО - в исключительно объектной модели работы с метаданными. Если бы их можно было запросом получать, то скорость была бы выше - в запросе можно сразу для всех объектов зацепить со всеми полями через точку. А так чуть ли не каждая точка неизвестно какую лавину неявных запросов вызывает.
4. Николай Больсунов (boln) 02.04.11 14:03
Вообще для повышения быстродействия думаю вскоре провести рефакторинг. Сейчас вижу, что в коде формирования описаний у меня много галимо тупых ходов: например, передача параметром-структурой в процедуры списка индексов и объекта "все ссылки" - вместо того, чтобы вынести их в переменные модуля... В общем, поковырять код надо, - может, и на УПП станет быстрее работать :D
5. Сергей Ожерельев (Поручик) 03.04.11 01:23
(4) На УТ 11 время генерации дерева вообще-то терпимо, на других конфах не пробовал. Может и не стоит заморачиваться с сохранением метаданных. Это не настолько частая операция.
6. Евгений Люлюк (Evg-Lylyk) 08.04.11 08:30
(3) Метаданные можно получать динамически. Вообще считаю нерациональным когда такой объем данных обрабатывается, а пользователю нужна лишь часть. ИМХО их нужно получать по мере раскрытия веток...
Идея замена конструктора запросов 1С мне очень нравится... готов поучаствовать в подобном проекте
7. Николай Больсунов (boln) 08.04.11 09:23
(6)
1. Именно такой подход и реализован: получается лишь часть метаданных, потому что составляются описания лишь отмеченных пользователем таблиц.
2. Если выполнять получение по "мере раскрытия веток", то каждая ветка может открываться от секунды и больше, особенно при плохом канале (ведь при этом каждый раз будет происходить обращение к серверу, а сейчас все формируется за одно обращение к серверу, а все полученные структуры таблиц хранятся на клиенте). Вряд ли такая работа инструмента кому-нибудь понравится - по сложившемуся стереотипу ветка должна раскрываться мгновенно.
3. Встает вопрос: ссылочные типы тоже каждый раз получать при открытии ветки, или запоминать? Если каждый раз получать, то снова тормоза и нерационально. Если запоминать, то накладные расходы будут не меньше, чем в существующем варианте - и при этом ничуть не уменьшится число обращений к серверу.
4. Лично я был бы вполне доволен, если бы разработчики 1С распространили работу Конструктора запроса на тонкий клиент. Тогда все заботы были бы сняты.
8. Евгений Люлюк (Evg-Lylyk) 08.04.11 09:59
(7) 1-3
Видимо мы говорим о разных вещах
Я увидел это
"файл серилизации получался чуть не 10 Мб"

И хотел сказать что предв. загрузка метаданыых и их описания не нужна... В 1С есть кэширование метаданных его более чем достаточно.
Суть подхода загружать только необходимый минимум если пинг до сервера не в секундах... все будет загружатся мгновенно.
Если "каждая ветка может открываться от секунды и больше" то предвар. загрузка всех метаданных будет в десятки раз больше при старте
Ответ по 3 если ветка раскрыта то уже все загружено и загружать повторно не надо
Есть конечно смысл в том чтобы одним запросом к серверу собрать все данные и потом не обращатся, но как мне кажется не рациональный подход. Тем более что при использовании дин. метода можно легко переходить к полному получению метаданных т.е как бы гибридный метод.

4. Да зачем им (в 1С) это делать!? есть же Толстый клиент (управляемое приложение). Тем более когда ты делаешь конструктор сам как в вашем случае ты можешь наделить его доп. функционалом.
9. Николай Больсунов (boln) 08.04.11 10:30
(8)
Весь вопрос в том, чем определяется этот "необходимый минимум".
А как работать с кэшем метаданных - это те же методы свойства? Если те же, то выигрыш в скорости будет незаметен.

"Если ветка раскрыта..." - а если в другой ветке имеется ссылка на тот же тип, что делать? Загружать или не загружать?

Вообще это мы все теоретизируем, а надо провести эксперимент.

Толстый клиент отмирает, как выражается тов. Радченко, "толстый клиент - это атавизм". Это промежуточные возможности для полного перехода к работе только с тонким клиентом.
10. Евгений Люлюк (Evg-Lylyk) 08.04.11 11:15
"необходимый минимум"

нужно пользователю видно выводить
А как работать с кэшем метаданных - это те же методы свойства? Если те же, то выигрыш в скорости будет незаметен.

Повторное обращение проходит быстрее
"Если ветка раскрыта..." - а если в другой ветке имеется ссылка на тот же тип, что делать? Загружать или не загружать?

Загружать = Строить ваше дерево метаданных - то да загружать естественно
Вообще это мы все теоретизируем, а надо провести эксперимент.

Какого рода эксперимент? Давайте поставим задачу конкретнее.
Толстый клиент отмирает, как выражается тов. Радченко, "толстый клиент - это атавизм". Это промежуточные возможности для полного перехода к работе только с тонким клиентом.

Да я буду только рад если они сделают
11. Николай Больсунов (boln) 08.04.11 13:27
(10)
Evg-Lylyk пишет:
Какого рода эксперимент? Давайте поставим задачу конкретнее.
Вообще подумал-подумал - Ваша идея теоретически хороша: если при обращении к серверной операции с метаданными перед разворачиванием узла не будет ощутимой визуальной задержки, то это позволит избежать ожидания построения дерева, которое имеет место сейчас. Если же будет задержка хотя бы порядка секунды, то это уже плохо: дерево просто обязано разворачиваться мгновенно, пользователя будет колбасить от такой работы, он будет нервничать и щелкать по "плюсику" снова и снова... Проверю на опыте.
Evg-Lylyk; +1 Ответить
12. Николай Больсунов (boln) 16.04.11 20:48
1. Исправлены две ошибки описания таблиц объекта Задача.
2. Добавлена работа с объектом Последовательность.
Поручик; +1 Ответить
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа