There’s been much fear surrounding the topic of field IDs within AX. While it is very warranted, I hope this post takes some of the apprehension out of your next code transition between AX environments.
As you well know, the problem is most likely to surface when moving bits of code and portions of AOT over (rather than the full environment xfer). Today was my first attempt to move a snippet of a project over for my supervisor, where a table definition was involved which included a new field. I usually get all nervous when these requests are made and ask if there’s anyway the change can wait until the next environment transfer. For whatever reason, I felt like taking on the challenge of an incremental code move…
Within the project that my supervior worked on, there was one AOT “table” involved. Right-clicking the AOT table and selecting “Compare…” allows me to see exactly what change I can expect…
Above, I can see he created a new ReceipientAccount field, which received an id of 40001
(yes, I know, it’s mispelled.. but.. too late to change by the time I wrote this)
Note: CUS layer id’s start in the 40000′s
Note: Field IDs are table scoped.. so the first field we add to a given table gets an id of 40001
I discovered that I can look at all the field IDs as they currently exist in the AOT, by running this query on the database:
SELECT [TABLEID]
,[FIELDID]
,[ARRAY]
,[NAME]
,[SQLNAME]
,[FIELDTYPE]
FROM [ax2009_dev].[dbo].[SQLDICTIONARY]
WHERE FIELDID > 40000 AND FIELDID < 50001
Notice that the WHERE clause restricts the field IDs exposed. In this case, field IDs are all limited to the CUS layer.
(IDs in the range 1-20000 are used for SYS layer objects, whereas objects in the VAR layer use IDs in the range 30001-40000. Prior to running the above SQL query, I verified that there was no extaneous/accidental work performed in the USR layers of both environments)
I ran the query against DEV (where the new work was performed) and got 132 records. I ran it against PROD, and saw 131 records. This makes me happy and fits exactly within my expectations. Here’s a picture of the record in DEV that I expect to see show up in the PROD after I perform my AOT export / import:
Thus, since I have verfied that the field ID’s are essentially the same between both environments (except for the 1 new field) I chose to NOT export field IDs when I created the .xpo file from DEV. I also chose to uncheck the “Import Field ID” field during the import to PROD. I am going to allow the AOT to auto-assign the field id (just the way Steve did when he created the field originally).
Upon completing the import to PROD, I re-run the above query and get 132 records in PROD and the new field ID does indeed match!
While this may have been a scenario where it would have been O.K. to “import field ids”, I think the ultimate goal is to allow auto-assignment to do it’s job.. and perform code transitions in such a way as to set up auto-assignment for success.
