Table & Field Numbers - SQLDICTIONARY

Ever wondered how to lookup a table ID using a SQL statement or how tableid2str works?  The hidden table SQLDICTIONARY has the field and table numbers from the shown in the AOT.  It also includes the size and type of the columns.

For the anal retentive you can update data in this table to reorder the columns in the AOT.  They are ordered by table ID and field ID.  Or even better, just create the fields in the order you want them and don't bother modifying a hidden system table.

Seldom when copying data from one environment to another, but not moving the code table IDs and/or field IDs (sometimes added fields were added in different order) were different.  Synchronization fails for those tables.  I have found three ways to remedy it.  Other times you may see a SQL error message when opening the form for the table.

Case A: Similar Columns with different IDs - Offhours
AX is confused because although field MyNewField exists as a date in SQL Server the field with that ID in the SQLDICTIONARY table is a different name, or even a different field type.  The error message is slightly different but both can be solved this way...

1. Go to SQL and rename the table, i.e. CustTable_OLD
2. In AX perform compile and synchronize on just the table, i.e. CustTable.  If you do a full compile you run a small risk that the renamed table in SQL will be deleted
3. Write an INSERT INTO...FROM statement to bring the data back into the table (RecIDs and all) - it will not cause an issue with record IDs.
4. Delete the previous table, i.e. CustTable_OLD

Case B: Similar Columns with Different IDs - Online
Sometimes you need to fix the table quick and without any delay.  I have in the past been able to change the field or table IDs by modifying the records in the SQLDICTIONARY table.  Just make sure that they are unique and agree with the layer rules, for example IDs coming from the CUS and CUP layers begin at 40000.  This should not require you to restart - just recompile and synchronize the table.

Case C: Development
Delete the table!  you have lost all the data but it is the easiest and fastest way to fix the issue.