Сохранение запроса

[Peter Savintsev]

Кто-нибудь пробовал сохранять Query в поле таблицы? Использование методов query.pack() и query.unpack() не устраивает, т.к. они сохраняют только один датасорс (то есть если мы при интерактивном редактировании запроса добавим дочерний источник данных, он сохранен не будет). Ппоробовал воспользоваться классом SysQueryEdit, но он тоже не очень правильно работает с дочерними датасорсами...

[Wamr]

Цитата:

Использование методов query.pack() и query.unpack() не устраивает, т.к. они сохраняют только один датасорс (то есть если мы при интерактивном редактировании запроса добавим дочерний источник данных, он сохранен не будет)

А можно полюбопытствовать как изменял, сохранял, проверял?

[slava]

может я не того dataSource принимаю за дочернего, но у меня они сохраняются. Другая проблемма, что я не знаю способа удалить их оттуда

[Wamr]

Простых способов удаления нет. Где-то на форуме был самописный классик выполняющий данную операцию.

[mazzy]

1. Зачем?

2. Чем не устраивают статические query, а в таблице хранить имена этих статических query?

3. Чем не устраивает динамическое создание Query на лету?

4. Думал о том, что сохраненный в таблице Query может быть восстановлен на другой конфигурации, где таких таблиц и полей нет? Будешь делать обработчик ошибок? В какой момент после чтения из таблицы ты собираешься включать обработчик ошибок? Что он будет делать? Опиши хотя бы на верхнем уровне? Он будет проверять идентификаторы таблиц и полей?

5. Повторю вопрос: чем не устраивает динамическое создание Query на лету?

6. И снова повторю вопрос: Ты все еще уверен, что не хочешь использовать статические Query?

[slava]

Цитата:

Изначально опубликовано Wamr
Простых способов удаления нет. Где-то на форуме был самописный классик выполняющий данную операцию.

Я немного слукавил когда сказал что не знаю способов. Администрирование/База../SQL/SysLastValue и там удалять строку для данного объекта.
А вот простых (несамописных) способов действительно кажется нет

[Андре]

Я вот так сохранял. Работает.

PHP код:

    xsysLastValue::saveLast(this);
   queryFilter = inventTable_ds.queryRun(); 


Если я конечно правильно понял вопрос.

[Андре]

Цитата:

Использование методов query.pack() и query.unpack() не устраивает

Прочита внимательнее - сам все понял. Прошу прощения.

[Peter Savintsev]

Цитата:

А можно полюбопытствовать как изменял, сохранял, проверял?

Пожалуйста:

PHP код:

    if (SavedQuery.Query)
    {
        q           = new Query(SavedQuery.Query);
    }
    else
    {
        q           = new Query();
        q.addDataSource(TbaleId);
    }

    qr              = new QueryRun(q);

    if (qr.prompt())
    {
        SavedQuery.Query   = q.pack(); //как вариант qr.pack(), тоже не работает
        SavedQuery.update();
    } 


SavedQuery - таблица, куда надо сохранять запрос, поле Query - контейнер.

Честно говоря, не понимаю, как получилось сохранить дочерний датасорс, который был добавлен интерактивно. В хелпе к методу Query.pack() так и сказано, что динамические ссылки не сохраняются...

2 mazzy. Нужно это для того, чтобы генерить настраиваемые отчеты (не стандартные репорты, а, скажем, web-отчеты). Сначала настраивается таблица, откуда должны браться данные, потом для этой таблицы настраиваются фильтры, то есть Query. Причем часто кроме фильтров на поля собственно таблицы необходимо наложить ограничения на связанные тыблицы (элементарный пример - получение суммарной стоимости запасов на каком-либо складе, как известно, для этого приходится связывать InventSum и InventDim и делать фильтр по InventDim.InventLocation).

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

[Wamr]

Цитата:

SavedQuery.Query = q.pack(); //как вариант qr.pack(), тоже не работает

Остался 3ий вариант:
SavedQuery.Query = qr.query().pack();

"динамические ссылки" - это dynalink... точно не сохраняются

[Peter Savintsev]

Цитата:

Остался 3ий вариант:
SavedQuery.Query = qr.query().pack();

Не, dynalinks не идут .

[mazzy]

тогда я не понял.

о чем вопрос то?
1. о сохранени параметров запроса (LastValue)
2. о том, чтобы сохранить где-нибудь сам запрос, его структуру?

если 2 вариант, то думаю стоит посмотреть на мастер отчетов.
он и генерит динамически и сохраняет. Причем сохраняет даже в АОТе.
Нужно выкинуть из него интерфейс и оставить ядро.

ИХМО, неправильный это подход.
ИХМО, от незнания.
Количество вариантов запросов конечно и не так уж и велико. Измеряется десятками.
ИХМО, проще предварительно подумать что нужно и сделать запросы статическими.
ИХМО, это на порядок уменьшит ваши общие трудозатраты на эту задачу.

Т.е. ИХМО не стоит делать универсальную хренотень, которая будет работать с всего лишь с десятками объектов. Она не окупится на таком небольшом количестве. Стоит просто перечислить эти несколько десятков запросов. Сильно сэкономите на разработке хренотени

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

[Wamr]

Пришлось писать пример... вроде работает
или я не уловил идею? dynalinks в данном контексте вообще не существует

PHP код:

static void Job_Q2con(Args _args)
{
    container   con;
    Query       q;
    QueryRun    qr;
    ;

    q = new Query();
    q.addDataSource(tableNum(InventTable));

    con = q.pack();
    info(q.exportXML());

    qr = new QueryRun(q);
    qr.prompt();

    con = qr.query().pack();
    q = new Query(con);
    info(q.exportXML());
} 


[Peter Savintsev]

Цитата:

Т.е. ИХМО не стоит делать универсальную хренотень, которая будет работать с всего лишь с десятками объектов. Она не окупится на таком небольшом количестве. Стоит просто перечислить эти несколько десятков запросов. Сильно сэкономите на разработке хренотени

В том-то и дело, что совсем не факт, что объектов будет десяток. И потом, даже если и их и немного, то при появлении каждого нового придется лезть в AOD, создавать новый Query, потом его настраивать... К тому же сами Rangе'и придется все равно хранить в настроечной таблице, т.е. все равно надо что-то придумывать. Зачем, когда можно сохранить готовый Query, а потом его просто использовать? Или ты предлагаешь для каждого фильтра создавать свой Query? ИМХО очень нерационально.

Цитата:

о чем вопрос то?
1. о сохранени параметров запроса (LastValue)
2. о том, чтобы сохранить где-нибудь сам запрос, его структуру?

Да, в сохранении именно параметров запроса. Но не просто всех ренджей и сортировки. А еще и всех присодиненных источниках данных, которые, как известно в форме редактирования добавляются через контекстное меню (сначала выбирается тип связи 1:n или n:1, поотм присоединяемая таблица).

2 Wamr. Dynalinks добавляются не в коде, а интерактивно в форме редактирования запроса. Они-то и не сохраняются.

[mazzy]

Цитата:

Изначально опубликовано Peter Savintsev
В том-то и дело, что совсем не факт, что объектов будет десяток.

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

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

Серебрянной пули нет. Как и волшебной кнопки, впрочем

Цитата:

Изначально опубликовано Peter Savintsev
Или ты предлагаешь для каждого фильтра создавать свой Query? ИМХО очень нерационально.

Для каждого фильтра, это конечно перебор.
НО в Аксапте есть стандартные средства как задать в статический Query диапазон.
Может стоит разобраться со статическими Query?

И почему нерационально, если Query в АОТе для этого и предназначены - хранить запросы. Почему выбран именно путь программирования и вы решили тратить свои ресурсы на замену стандартного механизма вашим?

Может дело в том, что вы просто сами не знаете что будет нужно?

Цитата:

Изначально опубликовано Peter Savintsev
Да, в сохранении именно параметров запроса. Но не просто всех ренджей и сортировки. А еще и всех присодиненных источниках данных, которые, как известно в форме редактирования добавляются через контекстное меню (сначала выбирается тип связи 1:n или n:1, поотм присоединяемая таблица).

Хм... еще вопрос.
в форме редактирования диапазонов (Ctrl+F3, форма SysQuery) можно сохранить запрос с диапазонами. Насколько я помню там сохраняется все в том числе добавленные таблицы. Чем не устраивает?

[Peter Savintsev]

Цитата:

в форме редактирования диапазонов (Ctrl+F3, форма SysQuery) можно сохранить запрос с диапазонами. Насколько я помню там сохраняется все в том числе добавленные таблицы. Чем не устраивает?

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

[mazzy]

Хм... сохранять можно под разными именами.
и не только последнее значение.

[Wamr]

Цитата:

... всех присодиненных источниках данных, которые, как известно в форме редактирования добавляются через контекстное меню (сначала выбирается тип связи 1:n или n:1, поотм присоединяемая таблица).

Так вот, это НЕ Dynalinks, а добавление новых dataSource в Query.
НЕ существует визуального средства добавления dynalink-ов.

Dynalink - это связь некоторого DS в Query с внешним курсором, а не с другим DS в том же Query

[Peter Savintsev]

Цитата:

Так вот, это НЕ Dynalinks, а добавление новых dataSource в Query.
НЕ существует визуального средства добавления dynalink-ов.

Действительно, в терминологии я немного запутался. Но суть не менятеся. Добавленные датасорсы не сохраняются. В том джобе, который ты сделал, добавленный датасорс появляется только благодаря тому, что query автоматически сохраняется в SysLastValue. Чтобы этого избежать, приходится делать так:

PHP код:

    qr = new QueryRun(q);
    qr.saveUserSetup(false); //это свойство запрещает сохранение запроса в SysLastValue
    qr.prompt(); 


В этом случае все ренджи пакуются, а добавленные датасорсы - нет.

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