Падает служба Dynamics AX

[ackid]

Всем привет !

Подскажи - может кто сталкивался. Проблема в следующем:

MS DynamicsAX 2012 R2 6.2.158.0
MS SQL 2008
Windows Server 2008 R2

Всё работало хорошо, но во время создания новой View на основе Query неожиданно вылетел AOT, смотрю в службы - служба не запущена.
Теперь после запуска службы, при открытии любого проекта, разворачивание ветки Tables в AOT,представлений....и в общем всего. Служба останавливается.
В логах windows поначалу писалось 2 ошибки:
1.

Имя сбойного приложения: Ax32Serv.exe, версия: 6.2.158.0, отметка времени: 0x50a65c76
Имя сбойного модуля: Ax32Serv.exe, версия: 6.2.158.0, отметка времени 0x50a65c76
Код исключения: 0xc00000fd
Смещение ошибки: 0x0000000000e4fb33
Идентификатор сбойного процесса: 0xec8
Время запуска сбойного приложения: 0x01cfd0ada08553f3
Путь сбойного приложения: C:\Program Files\Microsoft Dynamics AX\60\Server\MicrosoftDynamicsAX\Bin\Ax32Serv.exe
Путь сбойного модуля: C:\Program Files\Microsoft Dynamics AX\60\Server\MicrosoftDynamicsAX\Bin\Ax32Serv.exe
Код отчета: ce55a598-3ca1-11e4-906c-000c295b71de

2.

RPC exception 1726 occurred in session 3 process is Ax32.exe thread is 2528(User: Admin, ClientType: GUI)

Теперь же, при вылете появляется только первая ошибка.

Начал искать эту зловещую вьюху в SQLServer, но так её не нашёл.
Компилировать + синхронизировать не даёт - тоже вылетает.

Куда копать не знаю.
Про RPC exception 1726 - пишут что надо накатить заплатки, но все эти советы с 2007 - 2011 годов )))

[Maximin]

А я смотрю, баг-то старый так и не починили:
DAX2009. Запороть приложение (слой)

Раньше можно было в .aot файл залезть, а теперь, видимо, придется лезть в БД...

[ackid]

А можно поподробнее, хоть примерно что делать ... а то смотрю в книгу и вижу фигу ))) попробовал парочку советов сделать , но нечего не получилось ... как и раньше всё.

[Ivanhoe]

Версия у вас какая-то странная - почему не используете последний билд?

[Wamr]

О проверке метаданных

и к сведению

Цитата:

906188 Creating a self-referencing view triggers a stack overflow on the AOS

Product and version
Microsoft Dynamics AX 2012 R2

RESOLUTION
Will not be fixed

PROBLEM
When creating a self-referencing view, it triggers a stack overflow on the AOS.

REMARKS
Microsoft has evaluated this issue, and will not be issuing a fix at this time.

[ackid]

на этот вопрос к сожалению не смогу ответить... админю и обновляю не я :-(

[ackid]

Цитата:

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

О проверке метаданных

и к сведению

спасибо за ссылку, хоть с мёртвой точки сдвинулся. Нашёл я таки таблицу (вьюху) из-за которой пробела.
Но вот удалить
utilElement.delete();
не выходить , ругается -

Описание ошибки SQL: [Microsoft][SQL Server Native Client 10.0][SQL Server]
View or function 'MicrosoftDynamicsAX_model.dbo.UTILIDELEMENTS' 
is not updatable because the modification affects multiple base tables.

Хорошо, дай ка я найду её непосредственно в SQL, UtilIdElements - это тоже вьюха..а строится вся это дело на ModelElement - так вот что-то тут мне боязно удалять строчки, найти то нашёл.. но не будет ли хуже ?(

[Maximin]

Дык, удаляйте из БД, у вас других вариантов нет. Бэкапнуться не забудьте.
Хотя потом я бы вылил всё понапиленное и перелил бы на чистое приложение.

Цитата:

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

О проверке метаданных

и к сведению

Надо же - в 2012й они даже таки kb создали... Нашли, наконец-то после стольких лет. Это еще в 2.5, насколько помню, было.

[Wamr]

Цитата:

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

Это еще в 2.5, насколько помню, было.

Краш AOSа при создании view.....

[DSPIC]

Цитата:

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

Всё работало хорошо, но во время создания новой View на основе Query неожиданно вылетел AOT, смотрю в службы - служба не запущена.
Теперь после запуска службы, при открытии любого проекта, разворачивание ветки Tables в AOT,представлений....и в общем всего. Служба останавливается.

Скорее всего, когда вы перетягивали Quеry, ошиблись узлом - перетянули не в ветку Query а в ветку Datasource. Это гарантированно убивает слой еще со времен AX2009, как только появилась возможность строить View на основе Query. При любой попытке достучаться до такой битой View (в т.ч. На программном уровне через TreeNode) AOS складывается. Лечилось только удалением слоя. С тех пор у самого трясутся руки когда перетаскиваю Query во View дабы не промазать
Нужно как-то вырезать вью из SQL...

[ackid]

Да вы DSPIC абсолютно правы, я перетягивал query в Datasource....
Спасибо всем, помогли прямо таки выручили)))
delete from ModelElementData
delete from ModelElement
помогли, и я экспортнул все проекты....
Но всё равно думаю придётся удалять слой....

[Wamr]

Цитата:

KB 2929836 Application Object Server (AOS) crashes if adding a query under data source of view given the name of query and view is the same

Product and version
Microsoft Dynamics AX 2012 R2

PROBLEM
Application Object Server (AOS) crashes if adding a query under data source of view given the name of query and view is the same.

DESCRIPTION OF CHANGE
The changes in the hotfix resolve this issue.
Query should cannot be added to data sources of view if they were use the same name.

Вот такой KB еще есть. Может и не ваш случай и помощи от него мало, если уже все случилось.

[Maximin]

Цитата:

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

Скорее всего, когда вы перетягивали Quеry, ошиблись узлом - перетянули не в ветку Query а в ветку Datasource. Это гарантированно убивает слой еще со времен AX2009, как только появилась возможность строить View на основе Query. При любой попытке достучаться до такой битой View (в т.ч. На программном уровне через TreeNode) AOS складывается. Лечилось только удалением слоя. С тех пор у самого трясутся руки когда перетаскиваю Query во View дабы не промазать
Нужно как-то вырезать вью из SQL...

Спалил контору...

[DSPIC]

Цитата:

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

Спалил контору...

Да, признаться, я долго это не выкладывал этого в силу не допускать диверсии, но что тут уже поделаешь...

[Logger]

Недавно словили эту багу при работе в 2009-й аксапте.
В итоге разработали способ как это просто вылечить не удаляя слой.

Пусть для определенности у нас кривая вьюха на usr слое.
При любых попытках что-то сделать с ней аос падает по причине Падает служба Dynamics AX

1. Тогда берем другое приложение. Заходим там на usp слой. Создаем там вьюху с таким же именем и идентификатором.
2. Перекладываем usp слой в проблемное приложение.
3. Рестартуем аос
4. В итоге прямая вьюха на usp слое закрывает кривую вьюху и аос перестает падать.

Дальше лечим usr слой.
Запускаем на сервере джобик:

static server void main(Args _args)
{
    UtilElements        utilElements;
    Tableid             viewId = 50900; // поставить свой id вьюхи
    UtilEntryLevel      utilEntryLevel = UtilEntryLevel::usr;
    Identifiername      name    = 'Metadata'; // имя узла надо предварительно перепроверить при просмотре в обозревателе таблички UtilElements
    
    str                 str2Scan;
    void locView(str _str2Scan)
    {
        int     i;
        str     s;
        int     charCode;
        ;

        _str2Scan = strRem(_str2Scan, "\n\r");

        for (i = 1; i<= strlen(_str2Scan); i += 2)
        {
            charCode = str2int('0x' + substr(_str2Scan, i, 2));
            s += num2char(charCode);
        }

        info(s);
    }
    ;

    ttsbegin;
    flush utilElements;
    utilElements.disableCache(true);
    utilElements.skipTTSCheck(1);
    utilElements.ttsbegin();

    select forupdate utilElements
        where   utilElements.utilLevel  == utilEntryLevel
            &&  utilElements.parentid   == viewId
            &&  utilElements.name       == name // по идее может сработать и без этого условия
            &&  utilElements.recordType == UtilElementType::ViewQuery;
            
    str2Scan = BinData::dataToString(UtilElements.code);
    locView(str2Scan);
// throw info("Ну очень стремно удалять");
    utilElements.doDelete();
    utilElements.ttscommit();
    ttscommit;
}

В итоге кривизна вьюхи на usr слое вычищена.
Можно удалять usp слой.

P.S.
Возможно, что сработает и без манипуляция с usp слоем - я не пробовал. Нет желания повторять.

Если в джобе поставить переменную с типом utilIdElements то почему-то не срабатывает - отказывается редактировать или удалять запись с такими сообщениями:

Цитата:

Невозможно удалить запись в Application Model (UtilIdElements).
Номер записи не соответствует первоначальному номеру. Если таблицей используется весь кэш таблицы, это может быть вызвано тем, что этот кэш был сброшен. В этом случае следует перезапустить задание.

Цитата:

Невозможно отредактировать запись в Application Model (UtilIdElements).
Номер записи не соответствует первоначальному номеру. Если таблицей используется весь кэш таблицы, это может быть вызвано тем, что этот кэш был сброшен. В этом случае следует перезапустить задание.

Т.е. UtilElements и UtilIdElements ведут себя по-разному.
Интересно, почему так.

[DSPIC]

Цитата:

Если в джобе поставить переменную с типом utilIdElements то почему-то не срабатывает - отказывается редактировать или удалять запись с такими сообщениями

Кстати, если память не изменяет, utilIdElements & utilElements - это фейковые таблицы, их нет в DB. Манипуляции с ними ведут к прямым изменениям в AOD файле (честно говоря, даже не знал, что их типо можно редактировать). На них даже groupBy не работает, а по сему SQL-команды типа ttsbegin, skipTTSCheck и прочее вероятно можно опустить. Это слекга оффтоп, но до кучи.

[Logger]

Да, редактировать можно.
Тут еще AndyD выкладывал джобы как редактируя эти таблички можно менять идентификаторы объектов.

[Logger]

Цитата:

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

а по сему SQL-команды типа ttsbegin, skipTTSCheck и прочее вероятно можно опустить...

Да, вполне может быть.
Джоб несет атавизмы наших танцев с бубнами.
После достижения результата, я не стал перепроверять можно ли еще проще сделать.

UtilIdElements, падлюка, ведет себя совсем не так как UtilElements. Редактировать данные отказывается, вот мы и намучились с этим. Но стоило тип таблички поменять и удаление проскочило на ура.

[S.Kuskov]

А мне в своё время вот этот комментарий помог DAX2009. Запороть приложение (слой)
При должной сноровке можно и так

[Logger]

Ага, этот способ отложили на потом - как крайнюю меру. Стремно как-то туда лезть.