AX2009. Код для падения сервера

[kia]

Странно, но факт. Этот код при выполнении вызывает падение АОS.

static void Job1(Args _args)
{
    RHRMOrderTable  rHRMOrderTable;
    RHRMOrderTrans  rHRMOrderTrans;
    AZT_OrderTransEmpl  OrderTrans;
    ;
    select orderTrans
        order by EmplName
        where rHRMOrderTable.RecId == orderTrans.OrderTableRecId
           && (!rHRMOrderTrans || rHRMOrderTrans.RecId == orderTrans.RecId);
}

Связано с отсутствием в selecte поля таблицы rHRMOrderTrans. Наример: RecId
В Ах4 отчеты с подобным запросом работали на ура.

[samolalex]

В третьей версии Аксапты подобный запрос так же как в AX 4 отрабатывает без ошибки, но мне кажется, что запрет использования табличной переменной в условии запроса(where...) без указания конкретного поля в AX 2009 вполне логичным и правильным. Скорее всего, этот нюанс в пятой версии Аксапты был устранен.

А вообще запрос, по-моему, не очень корректный, т.к. табличная переменая rHRMOrderTrans в любом случае окажется пустой. Возможно так было бы правильней:

select orderTrans
 join rHRMOrderTable where rHRMOrderTable.RecId == orderTrans.OrderTableRecId
 outer join rHRMOrderTrans where rHRMOrderTrans.RecId == orderTrans.RecId;

[Lucky13]

Цитата:

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

Скорее всего, этот нюанс в пятой версии Аксапты был устранен.

А что в AX2009 вот так писать нельзя:

if (inventTrans)
{
...
}

Если можно, то чем этот код отличается от приведенного выше? Точно такое же условие.

[samolalex]

Цитата:

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

А что в AX2009 вот так писать нельзя:

if (inventTrans)
{
...
}

Если можно, то чем этот код отличается от приведенного выше? Точно такое же условие.

Я имел ввиду использование табличной переменной внутри запроса в условии (where...).

Цитата:

Если можно, то чем этот код отличается от приведенного выше? Точно такое же условие.

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

[Lucky13]

Цитата:

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

Он отличается тем, что в условии запроса не используется табличная переменая без указания поля, что может не вызвать ошибки в Ax2009.

Но ведь табличная переменная не используется в запросе, следовательно ничем не отличается от любой другой переменной. Такое выражение сначала преобразуется в true или false (в данном случае false) и после этого подставится в запрос. По крайне мере в 3.0 так. Про переменную, которая используется в запрос, насколько я понял, речи не идет.

[samolalex]

Цитата:

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

Но ведь табличная переменная не используется в запросе, следовательно ничем не отличается от любой другой переменной. Такое выражение сначала преобразуется в true или false (в данном случае false) и после этого подставится в запрос. По крайне мере в 3.0 так. Про переменную, которая используется в запрос, насколько я понял, речи не идет.

Табличная переменная используется в условии запроса. Под запросом я имею ввиду всю кодовую конструкцию после select, включая совокупность выражений после where.
А по поводу Ax2009 было сделано предположение об устранении возможности использования табличной переменной в условии запроса без указания конкретного поля.

[lev]

вообще на форуме уже обсуждался вопрос про использование неявного преобразования (не могу найти ссылку ), и в частности про условие существования записи в таблице.
Т.е. использование синтаксиса :

if (inventTrans)

или

if (inventTrans.RecId != 0)

связано это с тем, что определенное отрицательное значение RecId дает значение false, поэтому неявное преобразование приведет к тому что запись на самом деле есть, а условие не отработает. Поэтому необходимо всегда использовать вариант:

if (inventTrans.RecId != 0)

ну или в Вашем случае

where (rHRMOrderTrans.RecId == 0 || rHRMOrderTrans.RecId == orderTrans.RecId)

[lev]

нашел ссылку на тему Проверка на RecId

[Lucky13]

2 lev. Это понятно, но такая ситуация редкость и она не приводит к падению AOS, здесь же показано, что код гарантировано приведет к падению AOS. Нехорошо как-то

[lev]

Цитата:

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

2 lev. Это понятно, но такая ситуация редкость и она не приводит к падению AOS, здесь же показано, что код гарантировано приведет к падению AOS. Нехорошо как-то

Про то что АОС просто падает, да не хорошо, уж лучше бы такой код просто не компилился

[EVGL]

Теоретики... Неужели больше заняться нечем?

[Logger]

Цитата:

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

Теоретики... Неужели больше заняться нечем?

Ну к чему это ? Людям интересно.

Лучше бы взял да зарегал багу.

[EVGL]

Зачем мучать себя и Microsoft вещами, для которых есть явный workaround? Лучше сконцентрировать внимание на функционале, том, что реально волнует клиентов. К тому же, мы в компании такой SQL просто не пишем. В голову не приходит.

[Logger]

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

[kornix]

А на какой версии Ax2009 падает? Какая версия ядра? В последних обновлениях это вроде исправлено, по крайней мере 3 месяца мне мой когллега точно таким же способом демонстрировал несовершенство версии моего непропатченного ядра и стандартного приложения У меня падало, у него стоял AOS со всеми обновлениями - работало.

[kia]

Цитата:

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

А на какой версии Ax2009 падает? Какая версия ядра?

Ключевое слово в исходном сообщении было : Падение AOS

[gl00mie]

Вообще-то именно этот вариант заваливания именно этой версии АОСа уже обсуждался - см. Как завалить AOS AX 2009

[kia]

Цитата:

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

Вообще-то именно этот вариант заваливания именно этой версии АОСа уже обсуждался - см. Как завалить AOS AX 2009

А где-то обсуждалось в какой версии это уже исправлено?
Или когда будет исправлено