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

[Ivanhoe]

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

Цитата:

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

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

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

[Narayana]

Цитата:

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

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

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

Цитата:

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

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

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

[Narayana]

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

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

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

[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-запроса. (см. начало этого сообщения)

[oip]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

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

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