DAX 2009 RU5 - Ошибка компилятора в конструкции select

[sukhanchik]

Всем привет!
Наткнулся тут на интересную ошибку компилятора.

static void Job1(Args _args)
{
    DocuRef docuRef;
    CustTable custTable;
    ;
    select docuRef
        where docuRef.RefTableId == tablenum(CustTable)
        join custTable // Ошибка компиляции на этой строке
            where custTable.RecId == docuRef.RefRecId;
}

Что интересно, что ошибка проявляется исключительно на такой конструкции. Т.е. не воспринимается использование функции tablenum непосредственно перед оператором join.
Т.е. добавление между tablenum и join еще одного условия, например, написание так:

where docuRef.RefTableId == tablenum(CustTable) && true

перенос условия с tablenum после join, замена tablenum на custTable.TableId - все прокатывает.
Но в 2009 RU5 компилятор пишет "Синтаксическая ошибка", а в 4.0 SP2 - "Переменная join не объявлена"

[Волчара]

Поменяй одну строчку

        where docuRef.RefTableId == custTable.TableId

Получится конструкция не совсем корректная в смысле SQL но вполне корректная с точки зрения Axapta т.к. custTable.TableId - это константа...

[sukhanchik]

Цитата:

Сообщение от Волчара

Поменяй одну строчку

        where docuRef.RefTableId == custTable.TableId

Я ж изначально сказал что это прокатывает.

Цитата:

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

перенос условия с tablenum после join, замена tablenum на custTable.TableId - все прокатывает.

Дело-то не в том, как это обойти - а в том, что это достаточно неожиданная ошибка

[samolalex]

В Axapta 3.0 SP1 компилятор так же пишет о синтаксической ошибке после tablenum(CustTable). Поэтому я могу сделать вывод о том, что в 5 версии разработчики решили вернуться к прежним обобщенным спецификациям ошибок, а именно "Синтаксическая ошибка"

[sukhanchik]

[kashperuk]

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

Лечится просто - нужно объявить переменную, ей присвоить это значение, и переменную уже использовать в select statement.

[Logger]

Цитата:

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

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

Лечится просто - нужно объявить переменную, ей присвоить это значение, и переменную уже использовать в select statement.

Т.е. это фича, а не баг ? Исправлять не будут ?

[kashperuk]

Цитата:

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

Т.е. это фича, а не баг ? Исправлять не будут ?

Нет, это баг, конечно же.
Но исправлять пока/вообще не будут.

К счастью, есть простой workaround

[gl00mie]

Случайно наткнулся на свидетельство того, что разработчики стандартного приложения про этот косяк давно знают и нашли свой workaround без использования промежуточных переменных - см., например, \Classes\DirPartyMerge\runOnServer:

while select forupdate docuRef
    where docuRef.RefTableId == (tablenum(DirPartyTable))
    join partyTable
    where partyTable.PartyId == dirPartyId &&
          partyTable.RecId == docuRef.RefRecId

Т.е., оказывается, достаточно заключить tablenum в круглые скобки

[S.Kuskov]

В очердной раз наткнулся на этот баг. Ошибка воспроизводится не только с функцией tablenum, но и со всеми встроенными функциями из AOT\System Documentation\Functions