When you overlayered an application element (e.g. a method or a form) in Dynamics AX, a copy was saved in a higher layer. You modified the object there, therefore you ended up with two copies of the same element – the original one in a lower layer (such as SYS) and your modified one in …
Continue reading ‘Detection of code upgrade conflicts in F&O’ »
What I want to talk about today is a special case of code duplication: when we take an F&O application element created by some other company (Microsoft, ISVs or so) and create a copy in our model. Usually, people do it to deal with code that can’t be accessed or extended, e.g. when we want …
When testing my new rule for code upgrade tool, I found that certain objects are skipped and rules are not checked for them. That makes the tool significantly less useful, because you can’t be sure that it found everything. This blog post explains why it happens, but unfortunately doesn’t provide any reasonable workaround, except making …
The Code Upgrade Tool allows you to detect patterns in X++ code and even to automatically change code. It’s especially useful for code upgrade, because you can easily upgrade legacy code. For example, CompanyInfo.CurrencyInfo field was replaced by CompanyInfo::standardCurrency() method in AX 2012. To upgrade your code, you would have to find and fix all …
In AX2012 R2, model store database has been separated from business data database. For upgrade purposes, we have one more database – baseline model store. AOS configuration in Windows registry therefore contains keys for three database servers: dbserver ModelDBServer ModelDBServer_baseline (They’re stored at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Dynamics Server\6.0\02\{config name}\.) But if you open Microsoft Dynamics AX 2012 Server …