Recently, I came across an strange issue after doing model store deployment on client’s LIVE environment. Our client uses Dynamics Anywhere portal to run the production receipt process. After deployment, following error was thrown from \Data Dictionary\Tables\InventModelGroupItem\Methods\modelGroupNoThrow method when the receipt process is trying to create new pallet records, though the record was there in the table.

If the ModelGroupId field is not blank, there must be a record in the InventModelGroup table. If the record is not found, make sure the user has permission to perform a cross-company select on this table. The security framework will allow the select statement to return records for the companies in which the current user has explicit access of the tables involved. Therefore, it will return 0 records if the user does not have explicit access to the tables even if the tables are not AOSAuthorization-protected.

Interestingly, this error was not showing in TEST and REGRESSION environments. We can’t see any obvious reason why the above error message was only showing in LIVE and not in TEST. Then I found out that the code in the above method has been changed in later CUs for AX 2012 feature pack and in AX 2012 R3 as well. I worked with MS to get the hotfix which made the changes in this method. The hotfix code commented out the error message and made a second attempt to retrieve InventModelGroup item without crosscompany keyword. So, I though that this should resolve the issue, because the error message has been commented out and record is being retrieved in a different manner.

I did the deployment with hotfix code and bang! we got the same error message again. I was scratching my head and thinking, from where the error message was coming, because that was the only place from where the error message was coming and we had replaced it with the new code which doesn’t throw any error message. We did 4, 5 attempts of deployment with different steps in different sequence but in vain. Then I found a blog which mentioned similar issue related to BC session. After this, I decided to flush AOS cache using the instructions described in this blog post. There are three AOSes for client’s LIVE environment, so I performed the following steps:

  1. Start one AOS after deployment.
  2. Flush AOS cache using the instructions in the blog post, I mentioned above.
  3. Start other AOSes.

After doing the above steps in the sequence, I managed to resolve the issue and the error is gone. So, finally the BC session created through Dynamics Anywhere able to pick up the latest CIL code. Afterwards, I searched in LCS for this issue and found the following hotfix:

KB 2936094 SysGlobalObjectCache is not invalidated in multi AOS environment for common intermediate language (CIL) code

I checked with Microsoft about the above hotfix and technical support person confirmed that the above hotfix is addressing the same issue I described above. I didn’t know about this hotfix, so I ended up spending so many days and nights to resolve this issue.

Hope it will help other people who are facing the same issue.

Enjoy Daxing.

 

 

 

 

Advertisements