gifts2017

Хранение текстов запросов в справочнике и выполнение в общем модуле

Опубликовал Франко Деллиани (Franco) в раздел Программирование - Практика программирования

Описывается хранение текстов запросов в справочнике и их выполнение в общем модуле.

Дано: разрабатываемая конфигурация.

Требуется: оперативно править тексты запросов, не предлагая пользователям выйти из программы.

Решение: 1.определить тексты запросов в специальном справочнике и 2.Выполнять их в общем модуле.

Результат: В прилагаемой конфигурации есть документ 'Заказ', у которого выбираются контрагенты в зависимости от установки флага 'работает'/'не работает' в специальном регистре сведений. Кроме того, цена при добавлении товара также выбирается по дате.

Список контрагентов на 28.09.2013

Список контрагентов на 30.09.2013

Суммы на 28.09.2013

Суммы на 30.09.2013

Для хранения текстов запросов используется справочник 'Тексты запросов', а выполняются они в общем серверном модуле (общий модуль без вызова с клиента):

Тексты запросов

Текст модуля

 Функции передаётся текст и структура параметров (может не быть).

Переделана и консоль запросов – через контекстное меню можно получить из справочника и записать в справочник сам текст запроса:

 Консоль

Контекстное меню

Текст

В консоли

Идея взята из книги Гетц, Литвин, Бэрон 'Access. Сборник рецептов для профессионалов'.

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

Наименование Файл Версия Размер Кол. Скачив.
QueryTexts_8.3.4.295
.dt 128,38Kb
30.09.13
6
.dt 1 128,38Kb 6 Скачать

См. также

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

Комментарии

1. Дмитрий Лебедев (mr.Samuelson) 30.09.13 16:02
Боже, дык в конфе тысячи запросов. Не выносить же их все в справочники... Подобные частые переделки запросов только для отчетов наверное нужны, но при использовании СКД или там внешних отчетов - перезаход пользователей также не нужен.
2. ocnarf_ff (Franco) 30.09.13 16:13
...
Дано: разрабатываемая конфигурация.
...
3. Яков Коган (Yashazz) 01.10.13 00:10
Идея взята из книги Гетц, Литвин, Бэрон 'Access. Сборник рецептов для профессионалов'.

Оказывается, у этих товарищей и у меня идеи совпадают. Приятно узнать )))
Хотя мне больше нравится хранить фрагменты кода, в т.ч. и с запросами: http://infostart.ru/public/168168/
4. ocnarf_ff (Franco) 01.10.13 09:45
...мне больше нравится хранить фрагменты кода, в т.ч. и с запросами: http://infostart.ru/public/168168/
Grazie, Yashazz, за подсказку.
Кому-то, конечно, может и не понравится хранение кода в справочнике (?либо регистре сведений) - в каком-то отношении будут правы, например, сославшись на регламенты. Однако по мне идея прекрасна - можно использовать такую систему при разработке и отладке конфигураций. А выпускаемую в работу конфигурацию уже заполнять модули кодом.
И ещё - эту библиотеку можно использовать как сборник рецептов.
5. ффф ыыы (zqzq) 01.10.13 14:25
(2) Т.е. потом все эти запросы мигрируют в код? Не проще сразу там писать? А для отладки есть инструменты, например как в ИР вызывать из режима отладки функцию От(Запрос), которая в модальном режиме открывает консоль запросов с установленными параметрами, текстом.
6. Яков Коган (Yashazz) 01.10.13 19:04
Обсуждаемые возможности хороши, когда скелет конфигурации менять нельзя, а задача либо неясна, либо часто меняется. Плюсы - гибкость, минусы - трудности поддержки, отладки, прозрачности, целостности. Инструмент не для всех случаев, но иногда только он и выручает, когда надо вроде бы и штатно, и "по месту напильником". Лишь бы в конфе были такие места, предусмотренные для вмешательства напильником. Эдакие "порты", как бы.
Ну и, честно говоря, проще выбрать другой элемент справочника (и научить этому юзверя), чем комментить да раскомменчивать разные ветви кода или закладывать хитрую логику ветвления...
7. Алексей 1 (AlX0id) 02.10.13 08:57
Единственное применение для подобного метода, которое приходит в голову - это не разрабатываемая конфигурация, а база с огромным количеством данных, которые невозможно выгрузить в разумное время. И то с оговорками.
Динамическое обновление никто не отменял, собственно.
8. ocnarf_ff (Franco) 02.10.13 09:54
(7) AlX0id,
1.Динамическое обновление стараюсь использовать как можно меньше. Всё равно после 3-4-го обновления RPHost падает, создаётся дамп.
2.Работа на БОЛЬШОЙ базе и маленькой нисколько не различима - выгрузка здесь не при чём - запросы либо в конфигурации (и с данными не связаны), либо в справочнике. Выполняются в общем модуле.
9. ocnarf_ff (Franco) 02.10.13 10:00
(6) Yashazz,
Вновь же, на стадии отладки.
10. Ruslan (rus128) 02.10.13 10:08
Поставил бы "плюс", если бы текст исходников был на русском языке...
11. Алексей 1 (AlX0id) 02.10.13 10:18
(8) ocnarf_ff,
1. Ну это как бы проблемы Вашего сервера.
2. Значит, Вы не работали с БОЛЬШИМИ базами.

Как это выглядит на данный момент моими глазами: Вы пытаетесь перенести проблемы администрирования на программистов. Может быть, стоит завести нормального админа? )
12. ocnarf_ff (Franco) 02.10.13 10:18
(10) rus128,
спс, мне не сильно важно плюс.
Если желаете, для Вас переведу?
13. ocnarf_ff (Franco) 02.10.13 10:23
(11) AlX0id,
1.Не стоит ругать админа. В 8.2 при динамическом обновлении нет проблем.
Отладку запросов так делать легче чем при динамике - нет падений RPHost и нет сообщений пользователям.
2.Чем может быть отличаться конфигурация большой базы от конфигурации маленькой? При чём выгрузка в отладке запросов?
14. Ruslan (rus128) 02.10.13 10:35
(12) За меня не беспокойтесь - мои знания английского + 1С позволяют понять, какие методы вызываются.
а вот новичкам - возможно, было бы полезнее на русском прочитать...
15. Алексей 1 (AlX0id) 02.10.13 10:36
(13) ocnarf_ff,
2. Наверное, Вы правы в этом - объем данных будет влиять только в случае реструктуризации, а тут ваш механизм ничем не поможет.
16. ocnarf_ff (Franco) 02.10.13 10:45
(14) rus128,
Английский наше всё - так, кажется, выражение говорится?
Но всё-таки приму к сведению, благодарю. К тому методика разработки указывает на русский язык.
17. Александра Афанасьева (Ava_1c) 02.10.13 12:24
Успешно использовали похожий прием еще на 8.1.

Была самописная конфигурация, стояла задача классифицировать некоторые объекты. Под "классификацией" понималось присвоение объекту некоторой категории (категория - элемент справочника). Что-то вроде ABC-анализа номенклатуры/контрагентов, только сложнее.
Сложность была в том, что алгоритм "классификации" был довольно громоздкий с кучей условий. Каждое "условие" представили в виде отдельного запроса, которому на вход передавался список объектов, а в результате запрос этот список делил на два (подходящих под "условие" объектов и не подходящих) и дальше уже эти 2 списка передавались следующим запросам-условиям.. В конце присваивалась категория.
Этакое бинарное дерево из узлов-запросов с листьями-категориями.

Визуально все это рисовали в виде блок-схемы (самая большая классификация - на печати формат а1, больше 50 "условий" в схеме), получилось довольно наглядно. Каждый день обсчитывали по 4-5 классификаций, в каждой порядка 100к объектов.

Вся прелесть подхода в том, что можно было "на лету" добавлять новые "классификации" и изменять логику в существующих. Посмотрели на результат, подумали, схему поправили, тут же пересчитали.
По каждому объекту, кстати, добавили "отчет" в котором рисовалась полная схема классификации и закрашивался "путь из запросов", по которому объекту присвоили ту или иную категорию.
Руководство было в восторге. =)
18. Евгений Аганин (AganinEvgeniy) 02.10.13 12:46
(7) AlX0id, Ерунда. Главное тут сам принцип. А не конкретное его воплощение. Я допустим, привык пользоваться внешним построителем запросов или же просто в конфигураторе пишу внешние отчеты или обработки табличных частей. Но это не повод хаять на человека, за неплохую задумку. Меня тоже кстати всегда напрягает обновление базы, которое нужно провести ИМЕННО СЕЙЧАС, для выполнения задания директора. А в базе работает полно пользователей. И не говорите про динаму ... с этим сплошным глюком 1 раз столкнулся ... после восстановления бд из архива ... больше динамическим обновлением не пользуюсь. ПРИНЦИПИАЛЬНО! Даже когда нужно просто в отчете макет подправить. А этот вариант ... он ничем не хуже других и имеет право на жизнь.
19. ocnarf_ff (Franco) 02.10.13 13:00
(18) AganinEvgeniy,
Grazie.
Конечно же, это задумка для разрабатываемой, а не тиражируемой конфигурации.
PS.И динамика - это величайшее зло. Особенно в 8.3
20. Алексей 1 (AlX0id) 02.10.13 13:02
(18) AganinEvgeniy,
Как правило с проблемами при динамическом обновлении люди сталкиваются один раз - и после этого читают документацию. Если этот подход для вас неприемлем - ну не пользуйтесь демоническим обновлением - какие проблемы.
Я и не хаю особо - просто пытаюсь найти применение этому механизму. Пока не нашел )
21. Евгений Аганин (AganinEvgeniy) 02.10.13 13:27
(20) AlX0id, я в первый раз про динамическое обновление узнал на очном курсе 1с, проходившем в УЦ1, и опробовал его в деле ТОЛЬКО после этого (и кстати пользовался довольно аккуратно и только в случае обновления, которое не затрагивает данные в ИБ, такие обновления я всегда проводил в обычном режиме ... береженого свои боги берегут и чужие не трогают) и в одном из обновлений вылез косяк, что при обновлении только одного макета!!! в отчете у меня база полетела наглухо, в последствии вычитывал описание, а после уже курил форумы и описания ошибок, выявленых при том или ином обновлении. И не раз натыкался на то, что в том или ином релизе не корректно происходит обработка динамического обновления то из-за взаимных блокировок, то ещё по какой причине. По поводу того, что данный механизм мало применим на практике, согласен, но сам принцип довольно интересен. И думаю с него можно поиметь несколько реализаций довольно приятных. А если удастся это реализовать на полностью типовом решении ... цена такому решению будет очень высока. Во всяком случае я бы с радостью попытался использовать это.
22. Яков Коган (Yashazz) 03.10.13 09:36
(7) Какие бы сказки вам ни рассказывали про "это волшебное динамическое обновление" - наткнётесь на первый непредсказуемый косяк, угробите базу - тогда всё поймёте. Только ваших пользователей жаль.

(17) Решение, ссылку на которое я подкинул, появилось чуть ли не в 8.0 году так в 2006, а концепция была ещё в 7.7 и действовала через внешку-ert, модуль которой брался из формируемого файла. Ваше решение считаю красивым, сам до уровня блок-схем не доходил. Концепция правильная и на практике нужная.
23. Алексей 1 (AlX0id) 03.10.13 10:11
(21) AganinEvgeniy,
Ну, ребят, сколько уже с той поры утекло времени-то )
Мы постоянно осуществляем мелкие доработки конфигураций - все изменения, которые возможно - вносятся через динамическое обновление. Проблема с базой возникала раз или два. И то только из-за того, что нарушили регламент и не остановили фоновые задания.
24. Алексей 1 (AlX0id) 03.10.13 10:47
З.Ы. Повторюсь - против решения как такового не имею ничего против. Сами так делали, когда надо было настроить расчет зарплаты на одном предприятии.
Мало того - делали и построитель отчетов на базе справочника с СКД.

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

З.З.Ы. Чего бы уж сразу не сделать справочник с кусками кода тогда? )
25. Евгений Аганин (AganinEvgeniy) 03.10.13 14:17
(23) AlX0id, Согласен по поводу того, что проблема не частая ... но мне и 1 раза выше крыши хватило. Проще подождать окончания рабочего дня и уже нормально запустить обновление в монопольном режиме, чем потом страдать с восстановлением из бэкапа.
26. ocnarf_ff (Franco) 03.10.13 15:07
Если, конечно, есть окончание рабочего дня - а если работа ведётся все сутки?
Я использую динамическое обновление, но крайне осторожно, всегда есть копия, на которую настроен обмен.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа