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

[lvan]

Что-то вы не правильное делаете
Используйте формы (и, соответственно, датасорты) для отображения данных
Для обработки используйте классы

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

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

[Geo]

Большое спасибо за советы.

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

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

Цитата:

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

тоже не очень понимаю что нужно.
QueryRun - результаты, которые SQL-сервер отдает в ответ на Query

Вот это я изначально и хотел получить - результаты, которые SQL-сервер отдает в ответ на Query. Не по одной записи (как делает QueryRun.get()), а сразу всё, чтобы передать в метод и там обработать. Вижу по обсуждению, что такого в АХ не предусмотрено.

Цитата:

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

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

С терминологией я пока не до конца определился, но да: в моем понимании ltr является табличной переменной. А если сделать потом
Select ltr Where ltr.transDate == xx\xx\xxxх;
, то уж точно.

Цитата:

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

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

[mazzy]

Цитата:

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

Вот это я изначально и хотел получить - результаты, которые SQL-сервер отдает в ответ на Query. Не по одной записи (как делает QueryRun.get()), а сразу всё, чтобы передать в метод и там обработать. Вижу по обсуждению, что такого в АХ не предусмотрено.

Как это не предусмотрено?! *впал в ступор*

queryRun - это и есть результаты, которые SQL-сервер отдает в ответ на Query.

[Geo]

Цитата:

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

Как это не предусмотрено?! *впал в ступор*

queryRun - это и есть результаты, которые SQL-сервер отдает в ответ на Query.

Ну как? Вы же писали:

Цитата:

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

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

По-моему, это и означает, что взаимопреобразования QueryRun и Select в АХ не предусмотрено.

[Владимир Максимов]

Цитата:

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

Вот это я изначально и хотел получить - результаты, которые SQL-сервер отдает в ответ на Query. Не по одной записи (как делает QueryRun.get()), а сразу всё, чтобы передать в метод и там обработать. Вижу по обсуждению, что такого в АХ не предусмотрено.

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

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

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

А с Query, использующимися для форм вообще надо быть крайне и предельно осторожными, поскольку там образуется самая причудливая смесь фильтров в которую свою лепту вносит еще и сам пользователь. Как следствие, есть риск изменить не те записи или не изменить те, что нужно.

Поэтому, Вам нужно "знать" некий базовый Query, который не зависит от действий пользователя. И именно его и передавать как параметр в метод обработки. При этом "держа в уме", что то, что Вы передаете - не есть собственно данные. Это всего-лишь условия, по которым Вам еще только предстоит выбрать данные.

[Geo]

Цитата:

Сообщение от Владимир Максимов

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

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

Цитата:

Поэтому, Вам нужно "знать" некий базовый Query, который не зависит от действий пользователя. И именно его и передавать как параметр в метод обработки. При этом "держа в уме", что то, что Вы передаете - не есть собственно данные. Это всего-лишь условия, по которым Вам еще только предстоит выбрать данные.

Спасибо. Я об этом и думаю в последнее время: определить типичные важные поля, по которым может строиться фильтр, вытаскивать их условия из Query (если они там есть) и вручную строить Select с этими условиями, не забывая об ограниченности синтаксиса select'а по сравнению с query value.