Временные таблицы должны быть вложенными (inner)...

[Deep Dreamer]

Коллеги!

Столкнулся со следующей ошибкой, когда пытался на стандартной форме "Проводки по документу" нажать кнопку "Исходный документ":

Невозможно выбрать запись в 'Журнал отчетов по складским журналам' ('InventJournalReportTable_RU')
Временные таблицы должны быть вложенными (inner), когда вы объединяете их оператором join с постоянными таблицами.
(C) \Classes\Originaldocuments\findFromLedgerTrans - line 330
(C) \Classes\Originaldocuments\findRelations - line 6
(C) \Forms\Originaldocuments\Data Sources\TmpLedgerBase\Methods\linkActive - line 13


Ошибка возникает только в тонкой 3-звенке. В 2-звенке всё работает.

Сюда не отсылайте... Смотрел... Но проблема в том, что у нас ни одной доработки - всё стандартный функционал...

Всё это происходит в абсолютно чистом приложении Axapta 3.0 SP4 HF1 HF2.
Стоит Oracle 9.2.0.6.

Сначала подумал, что были какие-то изменения в классе OriginalDocuments в SP4, действительно были. Пробовал на SP4 вернуть старый вариант класса из SP3. Не помогло. После трассировки нашёл место "вылета" :

PHP код:

        while select inventJournalReportTable
                exists join InventJournalTable
                    where InventJournalTable.JournalId == inventJournalReportTable.JournalId
                exists join InventJournalTrans
                    where inventJournalTrans.JournalId == InventJournalTable.JournalId &&
                          inventJournalTrans.Voucher   == ledgerTrans_Caller.voucher   &&
                          inventJournalTrans.TransDate == ledgerTrans_Caller.transDate 


После некоторых безрезультатных хождений с бубном попробовал это же приложение натравить на базу в MS SQL... И о чудо! Всё работает. Стало быть виноват Oracle???

Возникает вопрос: как быть и что делать?

[Maxim Gorbunov]

Точно такая же ошибка была у меня на MS SQL. Правда в моей модификации. Думаю, что это клиент SP4 "виноват". Контролирует он теперь вложенность временных таблиц. В целом, конечно, это контроль правильный. А что делать? Так поменять запрос, чтобы временная таблица вложенной стала. А так как это код русского MBS, написать им письмо с приветом.

попробуйте разместить обе (все) таблицы на 1 стороне. На сервере.

PS сходил по ссылке... наверное, Вы уже попробовали frown

[Deep Dreamer]

Дык в том то и проблема, что у нас нет пока доработок - всё девственный стандартный функционал...

ну и что? глюки есть, были и будут.

[RVS]

"глюки есть, были и будут..."

ОсобливО в российском функционале "Их там ТЫСЯЧИ"

[AndyD]

Можно глупый вопрос?

В выше приведенном запросе нет временных таблиц. По крайней мере в моей версии. Может что-то поменяли в SP4?

[Maxim Gorbunov]

Честно говоря, не могу проверить, так как нет у меня русской версии под рукой. Но вряд ли. Согласно сообщению, inventJournalReportTable должна быть временной.

[AndyD]

Если судить по исходному коду этого метода, то переменная таблицы только объявляется, а затем используется в запросе. Т.е. инициализации для временной таблицы, если бы это было так, нет.

Может быть какой-нибудь глюк интерпретатора? А может ли быть так, что таблицы нет на сервере и интерпретатор считает, что она временная (в порядке бреда)?

Кстати, у себя специально проверял этот запрос - он целиком отрабатывается на сервере

[Maxim Gorbunov]

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

[Deep Dreamer]

В общем действительно временных таблиц там нет.
Там ещё очень странная вещь... Дело в том, что на InventJournalReportTable_RU стоит SecurityKey = InventJournals и ConfigurationKey = CSECIS. В нашем приложении нет модуля управления запасами, вот и получается, что права на SecurityKey = InventJournals у нас в принципе не могут быть назначены. Поэтому эта таблица у нас не может быть использована... И этот стандартный функционал класса OriginalDocuments пытается обратиться к таблице, на которой у нас нет и не может быть никаких прав!

Поскольку раскопки ничего не дали, я решил проблему банально: дописал примитивный if:

PHP код:

            if (hasSecuritykeyAccess(securityKeyNum(InventJournals),AccessType::View)) 


В нашем случае это спасло... Но вопрос всё равно остаётся открытым...

[Maxim Gorbunov]

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

CSECIS - это, наверное, CountryConfigurationKey? Потому что к складу он, вообще-то, отношения не имеет. ConfigurationKey у этой таблицы, наверное, другой?

[AndyD]

К таблице как раз таки привязан CSECIS, так что она должна быть (таблица), если включения локальная функциональность страны. Может какая-то проблема с синхронизацией?

[Deep Dreamer]

[Maxim Gorbunov]

Мда. Действительно. У таблиц CountryConfigurationKey нет. Только у MenuItem'ов. Прошу прощения.