AX 中识别被破坏的表对象 Identifying damaged Table objects in the AOT MetaData

最新推荐文章于 2023-01-07 20:21:34 发布

转载最新推荐文章于 2023-01-07 20:21:34 发布 · 689 阅读

标签

#table #object #layer #dictionary #crash

AX 技术专栏收录该内容

30 篇文章

订阅专栏

本文介绍了一种诊断和修复Microsoft Dynamics AX中损坏的元数据表对象的方法。通过使用X++作业，可以定位造成客户端或应用对象服务器崩溃的具体表，并提供删除该对象或重建受影响层的步骤。

Identifying damaged Table objects in the AOT MetaData

It happens very seldom, but sometimes the AOT MetaData is getting damaged, especially for Table objects.

Indications of such an element “corruption” can be that you have one explicit Table in the AOT and every time you access this object either the Dynamics AX Client or the Dynamics AX Application Object Server crashes. But the issue can also start earlier when you expand the Data Dictionary node of the AOT.

If you have no idea what Table could be affected the following X++ Job can help you finding out, by walking through the UtilIdElements Table touching each individual Table object:

static void findDamagedTableObjects(Args _args) 
{ 
    UtilIdElements util; 
    common tabBuff; 
    DictTable dt; 
    ; 

    //Look at all Tables 
    while select util where util.recordType == utilElementType::Table 
    { 
        /* Print out the name; the last element showing up here is 
           most likely the object causing issues... */ 
        print strFmt('Layer: %1 | Table Id: %2 | Table Name: %3', 
           util.utilLevel, util.id, util.name); 

        //This will eventually cause the Client or AOS to crash 
        dt = new DictTable(tablename2id(util.name)); 
        tabBuff = dt.makeRecord(); 
    } 

    print 'Completed without error!'; 
    pause; 
}

The Job accesses all Table Objects and lists them in the Print window. When the damaged element is reached the operation is stopped (e. g. because the AOS is crashing) so the last object showing up in the Print window is most likely the one causing the trouble.

Once you know the Table object causing issues, you could try deleting the object programmatically with the following X++ Job:

static void deleteDamagedTableObject(Args _args) 
{ 
    UtilIdElements utilElement; 
    UtilElementName tableName; 
    UtilEntryLevel tableLayer; 
    ; 
    
    /********************************************************************/ 
    /* Please adjust to the Table Name and Table's Layer to be removed! */ 
       tableName = 'NameOfDamagedTableToBeRemoved'; 
       tableLayer = utilEntryLevel::usr; 
    /********************************************************************/ 
    
    ttsbegin; 
    select utilElement where utilElement.name == tableName 
       && utilElement.utilLevel == tableLayer 
       && utilElement.recordType == utilElementType::Table; 
    
    if (utilElement) 
    { 
        utilElement.delete(); 
        ttscommit; 
    
        info(strFmt('Table object %1 in Layer %2 has been deleted!', tableName, tableLayer)); 
    } 
    else 
    { 
        ttsAbort; 
    
        warning(strFmt('Table object %1 in Layer %2 was not found!', tableName, tableLayer)); 
    } 
}

If attempting to delete the Table object with the previous X++ Job fails in any way, it will be necessary to rebuild the layer the damaged object is existing.

One possibility to rebuild a damaged layer is:

Create a new Project in the AOT
Specify a filter for all elements from the affected layer (don't use any grouping here, as this could again cause a crash)
Create another new Project and manually move all non-damaged objects from the first Project to the the other
Export the second Project as XPO (with IDs)
Stop the AOS and delete the damaged Layer’s AOD file (and AOI)
Start the AOS again
Re-import the XPO to the same Layer (now the corrupt object is gone)