Вычисления в таблицах

[Narayana]

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

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

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

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

В общем, стал я искать способ как-нибудь извратиться и использовать для обозначенной цели, например, View, Query, Temporary Table...
Неа, словно все сделано для того, чтобы предотвратить данную операцию.

С помощью формы такое можно сделать. Data Source формы позволяет добавить еще одно поле, не привязанное к таблице, которая является источником для Data Source и потом в методе дата-сорса вычислить значения и подставить их в нужное поле. Причем, ссылаться при вычислениях нужно на имя дата-сорса как на имя таблицы. При этом строки временной таблицы станут видны в форме.
Но во View или Query такое сделать невозможно.

View не позволяет создавать поле, независимое от таблицы-источника.
Query, - то же самое.

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

Я чего-то не понимаю или то, с чем я столкнулся, действительно, проблема в Аксапте?

[lvan]

Computed columns поддерживаются в View начиная с AX2012

[lvan]

вот даже разжеванное описалово нашел http://daxmusings.codecrib.com/2011/...n-ax-2012.html

[S.Kuskov]

Цитата:

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

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

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

Если просто отображать вычисленное значение не достаточно, то стандартный подход - использовать временные таблицы для промежуточных вычислений. Есть ещё не стандартный способ создания нужного View, заключающийся в том чтобы подменять аксаптовский View на нужный на уровне БД. Правда, как и у всех нестандартных способов, и у этого есть свои проблемы Запрет синхронизации объекта АОТ

[dech]

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

ThisIsMyTable mytable;
;

mytable.skipDataMethods(true);
update_recordset mytable
    setting
        field3 = mytable.field1 + mytable.field2;
    where mytable.field4 == "F4";

[Narayana]

Цитата:

Сообщение от S.Kuskov

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

Если просто отображать вычисленное значение не достаточно, то стандартный подход - использовать временные таблицы для промежуточных вычислений. Есть ещё не стандартный способ создания нужного View, заключающийся в том чтобы подменять аксаптовский View на нужный на уровне БД. Правда, как и у всех нестандартных способов, и у этого есть свои проблемы Запрет синхронизации объекта АОТ

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

Отображение вычисляемых значений в полях форм и отчетов возможно и удобно с помощью методов, но нужно не это. Нужно готовый View, для того, чтобы передавать его как дата-сорс в Data Set для портала.
Не, ну это, вообще, чисто идейно кривой ход, вычисления делать уже в форме. Вся смысловая бизнес логика должна реализовывать в единой структуре данных.
И потом, это же Аксапта, а не 1С. В общем, недоработка. Причем, крупная.

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

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

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

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

[Narayana]

Цитата:

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

Computed columns поддерживаются в View начиная с AX2012

Не, ну спасибо, канешна...!

[Narayana]

Цитата:

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

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

ThisIsMyTable mytable;
;
 
mytable.skipDataMethods(true);
update_recordset mytable
    setting
        field3 = mytable.field1 + mytable.field2;
    where mytable.field4 == "F4";

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

[S.Kuskov]

Цитата:

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

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

Это тоже самое. Разница только в области видимости. Если реализовать метод на уровне таблицы, то он будет доступен на всех формах и отчётах.

Цитата:

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

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

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

Посмотрите метод SetRecord
TmpTable в QueryRun

[George Nordic]

Если не требуется сортировка, то прочитайте про display и edit методы. Ничего сложного. Своего рода "виртуальное поле". Может доставить неприятностей при выводе на форму, для этого используется кэширование.

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

[dech]

А еще ты можешь скачать книжку на торрентах.
В ней есть все, что необходимо как начинающему так и программисту со стажем.
http://rutracker.org/forum/viewtopic.php?t=2110227

[Narayana]

Товарищи!
А можно такой вопросик...?
Давайте попробуем зайти с другого конца...
Вот, есть у нас в системе таблица. Та, которая лежит на SQL-сервере.
Судя по всему, эта штука не является экземпляром одного из классов Аксапты.
Далее, когда мы создаем переменную с типом конкретной таблицы, что происходит?
Создается экземляр класса xRecord? То есть, говоря по русски, Record Set?
И далее результаты операции select складываются в объявленную переменную таблицы?

А что тогда собой представляет то, что получается на выходе конкретного запроса?
Ну, то есть, чем является объединение нескольких дата-сорсов?
Определением структуры нового рекорд-сета?
И является ли запрос в АОТ экземпляром класса QueryRun?
Или класс QueryRun только предоставляет свои методы для использования в запросах?

[S.Kuskov]

Стоп, стоп, стоп. Не всё сразу. Это обсуждений на отдельную ветку потянет.

Не все элементы AOT являются "типами" в программистском смысле этого слова. Нельзя, например, обявить переменную типа tutorial_Form_Join, хотя такой узел присутствует в дереве AOT\Forms. Узел формы в AOT выступает в роли ресурса для инициализации объекта формы. Типом объекта формы всегда будет системный класс FormRun (AOT\System Documentation\Classes\FormRun)

С таблицами дело обстоит чуть по другому. Содание таблицы в AOT порождает появление нового типа данных в X++. Этот новый табличный тип представляет собой наследника системного класса xRecord. Дальше вы правы, выполнение команды "select" приводит к изменению состояния табличной переменной. Каждое выбранное из БД значение поместится в соответствующее поле табличной переменной.

Интересная деталь. В результате запроса не может появиться больше полей чем представлено в таблице. Простой пример. В аксапте нельзя одним запросом одновременной посчитать и минимум и максиму значений одного поля. Команд "select minof(myValue), maxof(myValue) from myTable" запишет в поле myValue табличной переменной myTable только одно значение.

Если в команде select участвуют несколько табличных переменных, то все они проинициализируются выбраными из БД значениями. Никакой новой объединённой структуры не создаётся (по крайней мере явно). Результат выборки полностью доступен через совокупность табличных переменных, участвующих в выборке.

Альтернативой встроенной в язык X++ команде "select" является механизм Query. Так же без Query не обойтись если запрос необходимо не просто обработать в коде, а отобразить пользователю через форму или отчёт.

Запрос в AOT (AOT\Queries) по аналогии с формами не является "типом", а
представляет некий ресурс, на основании которого может быть проинициализарован объект Query. Query стандартный класс (AOT\System Documentation\Query), который представляет объектный доступ к структуре запроса.

Не путайте класс Query и класс QueryRun. Если за конструирование (описание структуры) запроса отвечает класс Query, то за исполнение запроса ответственен класс QueryRun. QueryRun реализует обход запроса, и доступ к результату запроса.

[lvan]

Мне кажется, таким, как Кусков, нужно давать долю с продажи рекламы на этом сайте.

[Narayana]

Цитата:

Сообщение от S.Kuskov

Альтернативой встроенной в язык X++ команде "select" является механизм Query. Так же без Query не обойтись если запрос необходимо не просто обработать в коде, а отобразить пользователю через форму или отчёт.

Только было собирался спросить, не является ли запрос просто конструктором некоторой структуры для использования оператора select, как вот это ваше утверждение о том, что select и query, это два альтернативных механизма.

И в следующем посте от Сергея Мазуркина вижу "Грубо говоря, результатом работы Query является строка "select ... from ... where ... join" "

Товарищи Заслуженные Аксаптоведы, вы уж тогда между собой договоритесь...

[RVS]

Цитата:

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

Только было собирался спросить, не является ли запрос просто конструктором некоторой структуры для использования оператора select, как вот это ваше утверждение о том, что select и query, это два альтернативных механизма.

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

Narayana, вы сами поняли, что именно спросили? "Некоторая Структура Для Использования Оператора Селект".. внушает..

Цитата:

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

И в следующем посте от Сергея Мазуркина вижу "Грубо говоря, результатом работы Query является строка "select ... from ... where ... join" "

Товарищи Заслуженные Аксаптоведы, вы уж тогда между собой договоритесь...

Не сильно заслуженный, но - рискну прояснить:

И с помощью QueryBuild*, И с помощью встроенного select можно построить запрос к базе данных. Этот запрос можно выполнить, результат - использовать.

Так понятнее? )

===

А вообще - можно, конечно, задавать иди..тские вопросы.

А можно (альтернативно) - код посмотреть, в клаву потыкать (осмысленно), книжку почитать.. на худой конец.. Вы б попробовали, что ли )

[Narayana]

Цитата:

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

Narayana, вы сами поняли, что именно спросили? "Некоторая Структура Для Использования Оператора Селект".. внушает..

Думаю, если вы занимаетесь Аксаптой не позже, чем с 2003 года, то тем более должны были понять

Но, если не поняли, попробую детализировать собственное высказываение.
Если посмотреть в хелп по разработке, то можно увидеть, что оператор select стоит особняком от классов, их методов и функций, что наводит на мысль о его некоторой базовой роли.
Если вы что-нибудь слышали об устройстве аксиоматических математических моделей, то должны понимать, что такой подход наиболее эффективен для построения и изучения систем программных. А именно, очень важен порядок вещей. Что в основе, а что следствие. То есть, понимаете, очень редко бывает нагромождение из равноценных деталей. Так сказать с одинаковым приоритетом. Всегда иерархия.
Так вот, эту самую иерархию, с вашего позволения, я и выискиваю в интересующем меня вопросе.

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

Дак вот, читаем хэлп:
"
The select statement fetches or manipulates data from the database or both fetches and manipulates data from the database.
All select statements use a table variable to fetch records. This variable must be declared before a select statement can be executed.
The select statement only fetches one record, or field. To fetch additional records, you can use the next statement. The next statement fetches the next record in the table. If you use next without a preceding select command, an error occurs. Do not use next with the firstOnly find option. If you need to traverse a number of records, it is more appropriate to use a whileselect statement.
Results of a select statement are returned in a table buffer variable. If you use a field list in the select statement, only those fields are available in the table variable. If you use aggregate functions, such as sum or count, the results are returned in the fields that you perform the sum or count over. You can only count, average, or sum the integer and real fields. "

Этот кусочек текста в первую очередь наводит на мысль, что и создание объекта типа таблицы, вещь довольно первичная. И применение оператора select, тоже. Ведь этот оператор не является даже методом какого-нибудь класса, как я понимаю.
Чувствуете, на что намекаю?
Есть объектная модель языка X++ для Аксапты.
Эта модель предполагает стройную систему классов, методов и объектов.
А есть кое-что, что стоит как бы над этой объектной моделью.
Этакие торчащие уши, за которые система общается с внешним окружением.

Дак вот, я и предположил, что оператор select, это и есть нечто, лежащее вне объектной модели Х++.

Стало быть, конструкции внутри классов (не смущает слово "конструкции"?) могут использовать этот базовый оператор для работы с данными.
Ну и естественно, подумал, что методы классов Query...* вполне в своей внутренней реализации могут также использовать оператор select.
Ну, теперь понятно, борец вы наш за чистоту идеалов?

Цитата:

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

И с помощью QueryBuild*, И с помощью встроенного select можно построить запрос к базе данных. Этот запрос можно выполнить, результат - использовать.

Так понятнее? )

Вы меня, конечно, извините, но это и ежику понятно.
Речь, как вы уже поняли, шла о том, не является ли оператор select главным внутренним кубиком, с помощью которого строится QueryBuild и в словах Сергея Мазуркина я увидел намек, что является. А вот вы именно на этот вопрос не ответили.

Цитата:

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

А вообще - можно, конечно, задавать иди..тские вопросы.
А можно (альтернативно) - код посмотреть, в клаву потыкать (осмысленно), книжку почитать.. на худой конец.. Вы б попробовали, что ли )

Мне кажется, уважаемый RVS, что вы кушаете много жирного. Вследствие этого у вас эмоциональная реакция несколько опережает умственную

[RVS]

Очень много букв, цитировать не буду, звиняйте.. Итак :

Попробуем зайти с противоположного конца : select был всегда. По крайней мере, он появился вместе с SQL-сервером (могу ошибаться, но не сильно).

Axapta появилась несколько позже. Axapta работает с базой данных SQL.

Уже это наводит на некоторые мысли

В Axapta есть 2 способа получения данных из базы данных :

- написание явно, в коде Х++, select-стейтмента
- построение Query, который (внимание!) тоже выполнит некий select-statement
===
- Query можно построить "из кода" (семейство классов QueryBuild*)
- Query можно нарисовать в AOT

Вот, собственно, и все, что копья ломать?


Оператор Select, таким образом, не является "кубиком, с помощью которого строится". Оно "строится" для того, чтобы этот Select описать и затем выполнить (это я про Query)
===

Что до прочего - личного :

- мне видится, что вы не умеете формулировать вопросы
- мне видится, что у вас каша в голове пока что
- мне видится, что было бы знаком уважения к "знатокам Axapta" хотя бы попытаться разобраться (не начитаться.. терминов, а именно разобраться) в предмете. Прежде, чем задавать вопросы.

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

Воооот...

[mazzy]

Цитата:

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

И в следующем посте от Сергея Мазуркина вижу "Грубо говоря, результатом работы Query является строка "select ... from ... where ... join" "

Товарищи Заслуженные Аксаптоведы, вы уж тогда между собой договоритесь...

1. "следюущий пост" - это вот этот Query, где почитать?
2. противоречия нет.

есть следующие сущности. две из них имеют одинаковое название:
2.1. Query - объект, который позволяет строить СТРОКУ ЗАПРОСА вида "select ... from ... where ... join ...". Эта строка запроса так или иначе уходит на SQL-сервер.
2.2. QueryRun - объект, который принимает Query и фактически посылает строку на SQL, принимает результаты из SQL.
2.3. есть ОПЕРАТОР языка X++ select (http://msdn.microsoft.com/en-us/library/aa861766.aspx) (S.Kuskov назвает командой языка)
в результате выполнения оператора также уходит запрос на SQL-сервер и тут же принимаются результаты с SQL

так вот:
Query позволяет легко модифицировать СТРОКУ запроса программным образом.
Query позволяет работать с метасимволами поиска http://axapta.mazzy.ru/lib/search/
Query позволяет дать пользователю возможность модифицировать запрос
Query позволяет разработчику создать объект-прототип в AOT и потом легко создать запрос (Query q = new Query(querystr(myQueryInAOT)))

Query q = new Query(querystr(CustTable));
QueryRun qr = new QueryRun(q);
CustTable custTable;

while( qr.next() )
{
  custTable = qr.get(tablenum(custTable));
  info(custTable.name);
}

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

CustTable custTable;

while select custTable
{
  info(custTable.name);
}

различайте оператор языка X++ select и строку SQL-запроса, которая содержит select

[Narayana]

Цитата:

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

Попробуем зайти с противоположного конца : select был всегда. По крайней мере, он появился вместе с SQL-сервером (могу ошибаться, но не сильно).

Axapta появилась несколько позже. Axapta работает с базой данных SQL.

Уже это наводит на некоторые мысли ...

Безусловно, наводит.
И в первую очередь на мысль, что select в Аксапте, это не тот же самый select, что в родном для SQL-server select на sql-transact. Надеюсь, вы понимаете, что select в Аксапте даже не есть вызов SQL-серверного select. А если не есть, то и говорить не о чем, потому как к устройству Аксапты в нашем случае это отношения не имеет.
Но, вот в SQL server оператор select, скорее всего, появился тогда же, когда и механизм построения запросов. И скорее всего, они были в таких супружеских отношениях, как и в Аксапте.

"Query, который (внимание!) тоже выполнит некий select-statement"
"Оператор Select, таким образом, не является "кубиком, с помощью которого строится"."
"Оно "строится" для того, чтобы этот Select описать и затем выполнить (это я про Query) ""

ё-мое... ))
Если select выполнить, значит использовать. Если использовать, значит кубик. Не упорствуйте ))

"Что до прочего - личного :

- мне видится, что вы не умеете формулировать вопросы"

Я умею формулировать вопросы.

"- мне видится, что у вас каша в голове пока что"

Если бы у меня не было каши сейчас в голове, то этот сайт мне был бы не нужен.
По секрету открою вам одну тайну.
У всех каша в голове.
И у вас тоже

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

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