X++ in AX7: String truncation


Consider this X++ code: 

CustGroupId id = "012345678901234567890123456789"//30 chars long;  

CustGroup custgroup;   
custGroup.id = id;  
custGroup.insert;   

select custGroup 
   
where custGroup.id == id;  

The CustGroupID EDT is defined with a length of 20 characters. In AX 2012 the assignment in the very first line would truncate the string from 30 to 20 characters. The record would be inserted and selected again.

In AX7 the CustGroupID EDT is being compiled as the CLR type: string. The consequence being that no truncation occurs in the first line. The truncation happens in the data base layer, as the column can only contain 20 characters. The most significant change is in the select statement. In AX7 no record will be found, as no record has an ID matching the 30-character long ID. 

Actually; this also happens in AX2012 – when X++ code is compiled as CIL.

Is this good or bad?

I think it is primarily good. It is good - very good from a performance perspective. X++ is now compiled into CLR and is magnitudes faster than in AX2012. We could have injected a small check to validate and truncate every string upon assignment - at a quite dire cost. In the vast majority of cases the truncation isn't required - string lengths are already enforced, for example on the UI - so we opted for performance.

The only issues we discovered by this was in automated testing - like unit tests, where test data defined in code contained too long strings. In reality an implementation problem already in AX2012 - but it didn't surface until now. Once you know this change in behavior, solving the relatively few issues aren't a big deal.

 

THIS POST APPLIES TO MICROSOFT DYNAMICS AX7 TECHICAL PREVIEW; IS PROVIDED AS-IS AND CONFERS NO RIGHTS.

Comments (2)

  1. Thanks Yury.  I do not understand your concern. Can you share an example where this could lead to data corruption.

  2. Yury says:

    It sucks! That is very dangerous behaviour of the system. And it leads to overly cumbersome code because every developer should take into account a scenario when the datatype of the field will be changed by someone. Such type control bypassing is one of the major reasons of data corruption. And it happens all the time. Yes the source code is easy to fix, but the data is not.

Skip to main content