Преобразование datasource и query в табличный курсор

[Geo]

Так мне выделенность и не нужна, мне фильтры нужны. А целиком Table1 я пробовал на всякий случай.
Думал, есть что-нибудь вроде table_ds.tableVariable() или queryRun.tableVariable()

[kornix]

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

P.S.: QueryRun в качестве входного параметра использовать не желательно, т.к. обычно приходится добавлять условия в Query и получится такая картина: где-то был сформирован query, вы где-то от него сделали queryRun, потом передали его в метод, в методе опять получили от него query дополнили условия и т.п.

[CDR]

Цитата:

Сообщение от Geo

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

Цитата:

Сообщение от Geo

Так мне выделенность и не нужна, мне фильтры нужны.

Обрабатывать записи, выводящиеся в грид - не совсем правильно, т.к. в общем случае пользователь может и не видеть ВСЕХ отфильтрованных записей, которые выводятся в грид. Более того, аксапта может и не выбрать из БД все отфильтрованные записи для отображения на форме (например, условиям фильтра удовлетворяют 100 записей, на форме отображаются 15 записей, а в курсор из базы выбраны только 30 записей).

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

[Geo]

Цитата:

Сообщение от CDR

Обрабатывать записи, выводящиеся в грид - не совсем правильно, т.к. в общем случае пользователь может и не видеть ВСЕХ отфильтрованных записей, которые выводятся в грид. Более того, аксапта может и не выбрать из БД все отфильтрованные записи для отображения на форме (например, условиям фильтра удовлетворяют 100 записей, на форме отображаются 15 записей, а в курсор из базы выбраны только 30 записей).

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

Хм, но разве так делают в большинстве случаев, обрабатывают только явно выделенные записи? Мне казалось, в описываемых на форуме задачах как правило обращались к гриду, не рассматривая маркировку...

[mazzy]

Цитата:

Сообщение от Geo

Мне казалось, в описываемых на форуме задачах как правило обращались к гриду, не рассматривая маркировку...

нет. не надо обращаться "к гриду".
грид живет на клиенте. данные живут на сервере.
со всеми вытекающими последствиями для трафика и производительности
вам уже об этом говорили.

===============
по поводу "выделенных строк" см axaptapedia: Tutorial Form MultiSelectCheckBox
но обратите внимание, что "выделенные строки" и "отфильтрованные строки" - разные вещи.

[pitersky]

Цитата:

Сообщение от mazzy

нет. не надо обращаться "к гриду".
грид живет на клиенте. данные живут на сервере
...
но обратите внимание, что "выделенные строки" и "отфильтрованные строки" - разные вещи.

Именно поэтому в общем случае не обойтись без клиент-серверного трафика. Одно дело, когда мы запускаем обработку по записям с объективным уровнем общности (одинаковые значения полей, на которые можно наложить фильтр), и совсем другое - если пользователь хочет обработать произвольный набор записей, ничем не объединённый (кроме его доброй воли).

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

while select sum(Qty)
from MyTable
group by ItemId
{...}

Разворачивать здесь Query ИМХО = стрелять из пушки по воробьям. Т.е. можно, но зачем?

[mazzy]

Цитата:

Сообщение от pitersky

Одно дело, когда мы запускаем обработку по записям с объективным уровнем общности (одинаковые значения полей, на которые можно наложить фильтр), и совсем другое - если пользователь хочет обработать произвольный набор записей, ничем не объединённый (кроме его доброй воли).

да, но исходная тема совсем о другом
напомню

Цитата:

Сообщение от Geo

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

Цитата:

Сообщение от pitersky

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

while select sum(Qty)
from MyTable
group by ItemId
{...}

Разворачивать здесь Query ИМХО = стрелять из пушки по воробьям. Т.е. можно, но зачем?

А я бы стал хаять даже для таких "простейших" случаев.
хотя бы потому что в myTable может быть много миллионов записей.

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

еще раз посмотрите на исследование axaptapedia: Tutorial Form MultiSelectCheckBox

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

[pitersky]

Цитата:

Сообщение от mazzy

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

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

Цитата:

Сообщение от mazzy

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

Изначальный вопрос состоял в обработке набора записей в таблице, без уточнения способа отбора. Я вполне могу себе представить ситуацию, когда пользователь хочет обработать две-три отдельные строки, а не всё, что относится к фильтрованной выборке. Если принято решение, что такого быть не должно - тогда да, нам грид не нужен, достаточно серверной Query

[mazzy]

тоже не очень понимаю что нужно.
Geo, может сформулируете на человеческом языке исходную задачу?

Цитата:

Сообщение от Geo

Я думал, что QeuryRun это по сути и есть табличная переменная

Query - запрос
QueryRun - результаты, которые SQL-сервер отдает в ответ на Query
QueryRun - позволяет обратится к текущей полученной позиции (одна запись, если таблица одна, или по одной записи на каждую таблицу в запросе).
QueryRun.get() - метод, который возвращает данные в табличную переменную
табличная переменная - хранит данные из одной записи таблицы
внимание! если табличная переменная получена в результате select, то к ней можно применить next.

типичный пример работы с query

void job1(Args args)
{
    MyTable myTable;
    Query q = new Query(queryStr(myAOTQuery); // внутри что-то вроде select * from myTable;
    QueryRun qr = new QueryRun(q);

    while( qr.next() ) // в первый проход запрос отправляется на SQL-сервер
    {
        myTable = qr.get(myTable.TableId);
        ///....
    }
}

в форме:
myTable_ds.query() - запрос, который создал программист в AOT
myTable_ds.queryRun() - результаты, которые выводятся в форму. Будьте внимательны с позиционированием и next.
myTable_ds.queryRun().Query() - запрос, который действует в данный момент для данного экземпляра формы. Может отличаться от первоначального, если пользователь задаст фильтры, сортировку и т.п.

Цитата:

Сообщение от Geo

- а вот поди ж ты, никак не вытащить в явном виде, только по одной записи...

Что именно?

Цитата:

Сообщение от Geo

Это не то. Я хотел не пробежаться по записям, а сформировать одну табличную переменную, а-ля вызов "Select xTable Where ...", и потом хTable передать в метод, чтобы он с ней работал.

Что вы называете табличной переменной?
в следующем выражении
LedgerTrans ltr;

переменная ltr является табличной в вашем понимании?

надо отметить, что в Аксапте query и select-написанный-в-коде никогда не пересекаются. и никогда друг в друга не преобразуются. это два совершенно разных инструмента. Query никогда не преобразуется в select, а select никогда не преобразуется в Query.

Цитата:

Сообщение от Geo

Жаль; мне казалось, что табличная переменная - это удобно.

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

в "табличных переменных" и в select'ах не работают пользовательские фильтры с запятыми, восклицательными знаками и прочими символами.
кроме того, select нельзя динамически модифицировать.

Цитата:

Сообщение от Geo

Так мне выделенность и не нужна, мне фильтры нужны.

фильтры из Query не работают в select.

[George Nordic]

Цитата:

Сообщение от mazzy

надо отметить, что в Аксапте query и select-написанный-в-коде никогда не пересекаются. и никогда друг в друга не преобразуются. это два совершенно разных инструмента. Query никогда не преобразуется в select, а select никогда не преобразуется в Query.

Да ну?

QueryRun.query().dataSourceNo(1).toString();

С Уважением,
Георгий

[pitersky]

Цитата:

Сообщение от George Nordic

Да ну?

QueryRun.query().dataSourceNo(1).toString();

С Уважением,
Георгий

Я так подозреваю, что любой синтаксис в Аксапте (хоть селект, хоть query) всё равно преобразуется в язык SQL-запроса при передаче в обработку на сервере.