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

[RVS]

Цитата:

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

select в Аксапте, это не тот же самый select, что в родном для SQL-server select на sql-transact.

Синтаксис несколько иной, по сути - то же самое.

Цитата:

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

select в Аксапте даже не есть вызов SQL-серверного select.

Дааа? "А пацаны-то и не в курсе.."

Цитата:

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

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

Передергиваете

Вы спросили : "не является ли оператор select главным внутренним кубиком, с помощью которого строится QueryBuild"

Ответ : нет, не является "кубиком, с помощью которого строится QueryBuild". И вообще, QueryBuild - не строится, он строит. Строит Query, который при выполнении его из QueryRun выполняет тот самый SQL-серверный select. Включите трассировку SQL в Axapta, вы удивитесь, видимо

Именно это и имел в виду, говоря, что вы.. забавно задаете вопросы.

[Narayana]

Цитата:

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

2.3. есть ОПЕРАТОР языка X++ select (http://msdn.microsoft.com/en-us/library/aa861766.aspx) (S.Kuskov назвает командой языка)
в результате выполнения оператора также уходит запрос на SQL-сервер и тут же принимаются результаты с SQL

Ну, дак на SQL-сервер уже уходит запрос на sql-transact, как я понимаю?
Значит, все-таки кирпичик, связывающий Х++ с SQL-сервером?
То есть строки таблиц с SQL-сервера таскаются с помощью оператора select в Х++, а потом уже в соответствии со структурой запроса в Х++ формируются в конечный результат?

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

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

[Narayana]

Цитата:

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

Вы спросили : "не является ли оператор select главным внутренним кубиком, с помощью которого строится QueryBuild"

Хотите пообщаться на тему "Что может означать слово "строится"?" ?

[RVS]

Если только в Курилке

[S.Kuskov]

Цитата:

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

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

Почему так?

Скорее всего данное ограничение связано с тем что временные таблицы реализуются не средствами БД, а средствами AOS (приложением аксапты).
К слову сказать в версии AX2012 появились временные таблицы уровня БД.

Цитата:

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

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

Нет View это не способ вывести результат запроса (куда вывести?). View это реализация принципа повторного использования кода. Так сказать макрос уровня запросов.
Для вывода результатов запроса на форме или отчёте View не требуется. Просто укажите в свойстве Query узла "Data Sources" имя вашего запроса.

Если по каким-то причинам нужен именно View, то в качестве workaround можно попробовать в RunTime делать постоянную таблицу временной (см. метод xRecord.setTmp()). Либо для промежуточных вычислений использовать постоянные таблицы (потребуется самостоятельно изолировать данные между пользовательскими сессиями).

[Ivanhoe]

Сорри, что встреваю в разговор. Поддержу RVS, что Narayana "странно" задает вопросы. Просто имейте это в виду, когда "гуру" не смогут вам ответить, и проще будет сказать "Не знаю"

Цитата:

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

Ну, дак на SQL-сервер уже уходит запрос на sql-transact, как я понимаю?
Значит, все-таки кирпичик, связывающий Х++ с SQL-сервером?
То есть строки таблиц с SQL-сервера таскаются с помощью оператора select в Х++, а потом уже в соответствии со структурой запроса в Х++ формируются в конечный результат?

1. утверждение - верное.
2. оператор Select - один из кирпичиков. Формально - верное утверждение.
3. Вывод касается только оператора SELECT? Nогда первая часть утверждения верная, вторая часть - непонятная. =) Что такое структура запроса в X++? Если вы имеете в виду целиком оператор select с табличными переменными, выбираемыми полями и условиями - то да. Если вы тут пытаетесь опять к SELECT привязать Query - то нет.

[S.Kuskov]

Цитата:

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

То есть строки таблиц с SQL-сервера таскаются с помощью оператора select в Х++, а потом уже в соответствии со структурой запроса в Х++ формируются в конечный результат?

Что вы имеете в виду под фразой "с помощью оператора select"? Строки таблиц с SQL-сервера таскаются ядром аксапты, протоколы обмена данными разные задействованы... я думаю вас не это интересует.

Для организации подобного взаимодействия AOS<->БД на стороне SQL-servera используется механизм курсоров.

Когда обрабатывается команда X++ "select" или выполняется первая итерация цикла "while select", а также когда первый раз выполняется метод QueryRun.next(), на SQL-сервере происходит создание курсора "DECLARE CURSOR..." (не напрямую кончно, через вспомогательгы хранимые процедуры, но не столь важно).

Когда выполняется команда X++ "next" или выполняются последующие итерации цикла "while select" или QueryRun.next(), на SQL-сервере происходит движение курсора к следующей строке запроса "FETCH".

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

[Narayana]

Цитата:

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

Нет View это не способ вывести результат запроса (куда вывести?). View это реализация принципа повторного использования кода. Так сказать макрос уровня запросов.
Для вывода результатов запроса на форме или отчёте View не требуется. Просто укажите в свойстве Query узла "Data Sources" имя вашего запроса.

Для меня View, это возможность представить данные на очередном шаге бизнес-процесса. В частности, подготовить баланс расчета с агентами, для того чтобы вывести результаты на портале, куда агенты могут заходить в личный кабинет.
Ну, типа, подготовил то, что можно подставить в Data Set для портала и забыл.
В этом случае этот кусочек данных может использоваться и внутри Аксапты, и на портале. Только внутри это выведется в форме, а на портале в контроле ШейрПоинта.

[Narayana]

Цитата:

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

Если вы имеете в виду целиком оператор select с табличными переменными, выбираемыми полями и условиями - то да.

Да, именно это имею в виду.

Цитата:

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

Если вы тут пытаетесь опять к SELECT привязать Query - то нет.

Ну, хорошо, этот момент уже обстреляли со всех сторон, но повторюсь.
Оператор select я воспринимаю как аргумент функции (в математическом смысле) Query. При этом select имеет внутреннюю реализацию, описанную S.Kuskov-ым.

[Narayana]

Я имею в виду временные таблицы...

Mazzy пишет:
"2.1. Query - объект, который позволяет строить СТРОКУ ЗАПРОСА вида "select ... from ... where ... join ...". Эта строка запроса так или иначе уходит на SQL-сервер."

Понимаю, что выглядит как занудство, но...
Временная таблица живет в памяти или отдельно создаваемом для нее файле.
Если строка запроса "так или иначе уходит на SQL-сервер", то что получается, - временную таблицу запрос не обрабатывает и оператор select не действует?

[S.Kuskov]

Цитата:

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

Для меня View, это возможность представить данные на очередном шаге бизнес-процесса. В частности, подготовить баланс расчета с агентами, для того чтобы вывести результаты на портале, куда агенты могут заходить в личный кабинет.
Ну, типа, подготовил то, что можно подставить в Data Set для портала и забыл.
В этом случае этот кусочек данных может использоваться и внутри Аксапты, и на портале. Только внутри это выведется в форме, а на портале в контроле ШейрПоинта.

Чесно говоря, у меня недостаточно опыта работы с порталом, что бы утверждать, что предложенный мной workaround будет работоспособен из ШейрПоинта. Возможно более знающие люди вам смогут помочь.

Цитата:

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

Оператор select я воспринимаю как аргумент функции (в математическом смысле) Query. При этом select имеет внутреннюю реализацию, описанную S.Kuskov-ым.

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

Представьте, что в результате "компиляции" код X++ переводится на некий псевдокод, который потом ядро системы (интерпретатор) способно интерпретировать (выполнить). Так вот и команда "select" и вызов QueryRun.next() компилируется компилятором в "одинаковый" псевдокод. Это моё личное восприятие действительности. Вы можете воспринимать как захотите.

Один интересный факт сейчас вспомнил. В версии AX2009 появилась возможность реализовать UNION. Но возможность эта реализуется только посредством Query. Через синтаксис "select" реализовать UNION не получится. Это так, к слову о первопричинности

Цитата:

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

Если строка запроса "так или иначе уходит на SQL-сервер", то что получается, - временную таблицу запрос не обрабатывает и оператор select не действует?

Оператор select языка X++ применённый к временной таблице действительно НЕ инициирует реальный SQL запрос к БД.

[mazzy]

Narayana, в принципе, вам уже ответили.
но попробую и я вставить.

Цитата:

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

Ну, дак на SQL-сервер уже уходит запрос на sql-transact, как я понимаю?

отличный вопрос.
Прежде всего, хочу извиниться за упрощение.
Полностью утверждение выглядит так:
= строка запроса уходит в некий преобразователь запросов Аксапты.
= этот преобразователь диспетчеризирует запрос к
=== собственной базе данных (временные таблицы, псевдотаблицы UtilElements)
=== к кэшу (если у таблицы установлено свойство CacheLokup и запрос простой)
=== внешней базе данных (MS SQL, Oracle, ранее были my SQL и еще десяток других)

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

В большинстве случаев в конечном итоге срока запроса уходит таки на SQL.

Теперь еще внимание: начиная с AX2012 поддерживается только MS SQL, временные таблицы хранятся в MS SQL, псевдотаблицы с бизнеслогикой - также в MS SQL.

Поэтому начиная с AX2012 увтерждение "запрос на sql-transact" является верным.
Но вот до ax2012 это слишком жесткое утверждение. Вполне возможно, что запрос будет на PL/SQL. Вполне возможно, что запрос будет к собственной базе данных.

Цитата:

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

Значит, все-таки кирпичик, связывающий Х++ с SQL-сервером?

Да. Но добраться до этого кирпичика можно как оператором языка, так и объектом Query.

Цитата:

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

То есть строки таблиц с SQL-сервера таскаются с помощью оператора select в Х++, а потом уже в соответствии со структурой запроса в Х++ формируются в конечный результат?

Тут тоже упрощение.
оператор select в X++ - это синтаксический сахар.
Внутри происходят процессы, похожие на Query/QueryRun.

Обратите внимание на оператор next, который непосредственно связан с оператором select.
Вот такой код вполне валиден. Хотя и считается сильно устаревшим

CustTable custTable;

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

Цитата:

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

А как тогда все-таки с временными таблицами?

До ax2012 временные таблицы обрабатываются внутренним аксаптовским исполнителем SQL-запросов.
Начиная с ax2012 временные таблицы "живут" в MS SQL и обрабатываются обычным образом SQL-сервером.

Цитата:

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

Ведь View, это ведь просто способ вывести результаты запроса.

Нет, View - это материализованный запрос. Он живет на SQL-сервере с момента появления в ax4.0. До этого был только Query.

Цитата:

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

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

Вопросы просто отличные.
Но с какого-то момента вам нужно четко определить по какой версии вы задаете вопросы.
ax3.0, ax4.0, ax2009, ax2012 очень сильно отличаются в части внутренних механизмов работы с базой.

в ax2012 все живет в MS SQL. И все просто.
в более ранних версиях все гораздо запутаннее.

Цитата:

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

Зачем не давать использовать временную таблицу стандартным образом во View???

потому что view живет на SQL-сервере, а временная таблица (до ax2012) живет только в рамках AOS.

Цитата:

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

Понимаю, что выглядит как занудство, но...
Временная таблица живет в памяти или отдельно создаваемом для нее файле.
Если строка запроса "так или иначе уходит на SQL-сервер", то что получается, - временную таблицу запрос не обрабатывает и оператор select не действует?

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

[mazzy]

Цитата:

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

Через синтаксис "select" реализовать UNION не получится.

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

Цитата:

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

Оператор select языка X++ применённый к временной таблице действительно НЕ инициирует реальный SQL запрос к БД.

Не только оператор. Query тоже не инициирует (до версии ax2012)

[mazzy]

Цитата:

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

Оператор select я воспринимаю как аргумент функции (в математическом смысле) Query.

Тоже позанудствую

ни в коем случае не "как аргумент".
только как "результат функции".

Query не умеет принимать и разбирать строку SQL-запроса. И никогда не умел.
Query умеет только строить строку SQL-запроса на основании других аргументов.

[oip]

Цитата:

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

Теперь еще внимание: начиная с AX2012 поддерживается только MS SQL, временные таблицы хранятся в MS SQL
...
Начиная с ax2012 временные таблицы "живут" в MS SQL и обрабатываются обычным образом SQL-сервером.

Не-не, "старые" временные таблицы же тоже остались.

[Narayana]

Уф... Столько интересного!
А можно тогда еще один очень важный для меня вопрос?

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

И вот, собственно, вопрос.
Что лучше, запускаться на Ax2009 или дождаться русского релиза Ах2012, потратить еще несколько месяцев на изучение и стартовать на Ах2012?
Тем более, что программные доработки, вроде бы должны встать и на новую Аксапту...

[S.Kuskov]

Цитата:

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

Что лучше, запускаться на Ax2009 или дождаться русского релиза Ах2012, потратить еще несколько месяцев на изучение и стартовать на Ах2012?

Обучение пользователей уже проводилось? Под AX2012 потребуется достаточно маштабное переобучение.

Цитата:

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

Программные доработки, вроде бы должны встать и на новую Аксапту...

Т.е. доработки изначально делались с таким прицелом? Если явно такого требования не было, то очень даже сомнительно.

[mazzy]

возвращаясь к исходному вопросу.

Цитата:

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

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

как совершенно точно ответил Ivan: "Computed columns поддерживаются в View начиная с AX2012"

До этого предлагалось использовать Display/Edit методы на таблицах и/или на датасорсах формы.
http://msdn.microsoft.com/en-US/libr...(v=ax.50).aspx
http://msdn.microsoft.com/en-US/libr...(v=ax.50).aspx
и т.д.


А до этого (очень давно) предлагалось использовать метод postLoad таблицы. (устарело, не используйте)

Для display/edit методов было много чего придумано и сделано.
Главный принцип - на AOS попадает каждая запись из запрашиваемой таблицы. В этом случае display/edit подход отлично работал. (тогда поддерживалось несколько движков баз данных, вплоть до DBF)

но с версии ax3.0 в аксапту пришли групповые операции. И вообще, разработчики стали гораздо больше переносить тяжелые обработки на SQL-сервер. Начиная с ax3.0 поддерживаются только MS SQL и Oracle в качестве движков баз данных. а начиная с ax2012 - только MS SQL

В условиях групповых операций подход с display/edit-методами работает не очень.
Но пока вы не перешли на ax2012 других способов добавить вычислимое поле в форму или отчет нет.

Цитата:

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

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

да, это связано с совместимостью со старыми версиями аксапты.

Цитата:

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

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

Цитата:

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

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

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

Цитата:

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

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

Гы... вы еще dataset не посмотрели

Цитата:

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

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

Да, непонимание.
Скорее не проблема, а фича, связанная с совместимостью со старыми версиями

[mazzy]

Цитата:

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

И вот, собственно, вопрос.
Что лучше, запускаться на Ax2009 или дождаться русского релиза Ах2012, потратить еще несколько месяцев на изучение и стартовать на Ах2012?

Мое личное мнение, которое может не совпадать с мнением вендора и текущего работодателя:
погодите пока с ax2012. там слишком МНОГО изменений. пусть устаканятся чуток.

[oip]

Цитата:

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

Что лучше, запускаться на Ax2009 или дождаться русского релиза Ах2012

Ждать осталось совсем недолго. Всего три недели.

Цитата:

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

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

Я бы не был в этом так уверен. Смотря какие у вас доработки. И смотря сколько их. AX2012 R2 от AX2009 отличается ооооочень существенно.