Invalid value *** specified in the query predicate

April 8, 2020 at 13:32  (no comments)

Recently a customer logged a bug after moving there environment to new servers.
The batchjob “Notification clean up” went in error with the message

Invalid value (“07-07-2017”..”03-03-2020″) specified in the query predicate

The date range came from the DayRange functionality
It seems to be a Region setting on the server

The shortdate notification was dd-MM-yy
After changing the year yy to yyyy it all went well.

Keep in mind also to change the setting for the AOS service account

Workflow: invalid tracking submission expected context %1 and expected type %2 actual context %3 and actual type %4

January 27, 2020 at 16:25  (no comments)

You can get this error in the Workflow message processing batch job. You will find that the workflow batch throws this error every 10 minutes or so. The reason you get it every 10 minutes is because of the code in the SysWorkflowMessageQueueManager.expireLeasedMessages() method. In this method, the workflow updates the batch affinity value every 10 minutes.

To debug this issue, you might be tempted to process the workflow messages using the the Tutorial_BatchProcessing form. However, you will not be able to debug this using the Dynamics AX debugger because this form executes the function that fails in CIL. You will have to use Visual studio to debug it.
To debug using the Dynamics AX debugger, use the following job:

Set your breakpoints in the table method workflowtrackingtable.savetracking() on line 161 and/or 154. These are the lines that throw an error message with label @SYS112531.
Wait for about 9 minutes after the workflow batch has the status error, then run the job every 2 seconds manually. After about 1 minute of this you will enter the breakpoint. Then use the debugger to figure out what record in the table SYSWORKFLOWMESSAGETABLE is causing the error.
You could also find it using the following query:

This query returned more records than were causing the issue in my case, so it’s best to make sure using the debugger. I then “fixed” the issue by deleting the identified record from the SYSWORKFLOWMESSAGETABLE table.

If you run the Tutorial_WorkflowProcessinng class and you get the error every time, there might be something wrong with records in the table WORKFLOWWORKITEMTABLE instead. You can figure out what record this is using the debugger as well.

Most likely the work item is linked to a tracking status record that does no longer exist. Verify this using this query:

You can try to get it working by recalling the worklow and resubmitting it. If that doesn’t work you can delete the record in the WorkflowWorkitemTable table.

Unfortunately, I do not know the root cause of this issue but the actions above fixed it for me. Hope this helps. Thanks to the community for inspiration on how to fix this issue.

Dynamics AX 2012 Timezones

March 29, 2018 at 12:02  (no comments)

Just wanted to share this overview of the time zones used in Dynamics AX 2012 and the TZId value that is used to store UTCDateTime values in SQL.

SSRS: Empty fields on report – Part 2

March 20, 2018 at 20:12  (no comments)

Hi all!

Some time ago I talked about a problem with SSRS reports that were showing empty fields where data was expected. More recently I talked about how display scaling for high DPI displays can cause fonts in the Dynamics AX client to be all messed up. Today, these two issues kind of had a baby of some kind :).

Apparently, the display sizing setting can cause reports to show empty field when printing to client. When you print to PDF, all data is there. When on your host machine, display sizing is set to 125%, some reports can show empty fields. If you set it to 100%, the problem seems to be solved and the report prints correctly to the screen.
If you are working on multiple monitors, it is possible that it works when your remote desktop sessions is opened on one monitor, but the report shows empty fields when you open your remote on another monitor. As mentioned in the previous post, you also get different results when you change the Disable display scaling on high DPI settings property on the Dynamics AX 2012 shortcut.
In any case, it is best to set the display scaling on the client to 100% if possible to avoid these issues.

Management Reporter and Dynamics AX 2012: Users not synchronizing

March 16, 2018 at 17:06  (no comments)

Today Management Reporter did not want to synchronize the users from Microsoft Dynamics AX 2012 to Management Reporter.

TLDR: make sure that you do not have unknown users with access to Management Reporter in your database. For example users from a different domain or users that have been deleted on active directory.

As you probably know, the users in Management Reporter are actually managed in Dynamics AX by using the role based security of Dynamics AX. The following table shows which roles in AX correspond to which roles in Management report (Source). So for example if you want to be administrator in MR, you need to be Security administrator in AX.

Once you have setup the security in AX, it can take up to 5 minutes for the users to show up in Management Reporter. The synchronization of the users is part of the AX 2012 Companies to company task that is executed by Management Reporter every 5 minutes. You can check if this task has run in the Management Reporter 2012 Configuration Console. Go To Logs > Data mart integration and search the log for AX 2012 Companies to company. If it has executed successfully, the users should show up in Management Reporter.

If on the other hand there are errors in the AX 2012 Companies to company task, users will not be synchronized correctly. In my case, I had restored a database from another domain and there were users in the AX database with roles that gave them access to Management Reporter. Disabling these users in AX does not help, so you have to either remove them from AX or remove the role assignment that give the user access to Management Reporter.

Large and strange font sizes in menus for Dynamics AX 2012 on remote sessions

February 14, 2018 at 13:13  (2 comments)

Hi all!

When you open a Dynamics AX 2012 client (RTM/FP/R2/R3) on a remote session it sometimes looks pretty weird. Font sizes are all over the place and overall it doesn’t look that great. See for example in the following screenshot:

You can get better results by changing the properties of the shortcut if you check the checkbox Disable display scaling on high DPI settings on the Compatibility tab.

The result is better but still not entirely accurate:

You can get the best results by changing the display settings on you host system (so the PC or laptop you are working on). I have Windows 8.1 but you should find a similar setting on other versions of Windows in the Display section of the Control panel.
Microsoft recommends 125% scaling by default, but I prefer to set it at 100%. Setting it to 100% will also give you the best results for Dynamics AX 2012 in remote sessions. So, on your system, change the setting to 100% as seen in the following screenshot.

This property will only be active after you sing off and sign in again, so do that also.

If you connect to a remote session now, you will see that the scaling of the text in Dynamics AX 2012 is now accurate. This will improve your experience and your screenshots.

CombineXPO: Length cannot be less than zero

November 28, 2017 at 17:12  (no comments)

We are moving from AX 2012 FP to AX 2012 R3 and our daily build was failing with the following error:

Length cannot be less than zero

We have traced the problem to the xpo files in version control that contain the (shared) projects. When these are added to the XPO, you get the error above.

There is a blogpost here that explains the problem.
So apparently, when moving from AX 2012 FP to AX 2012 R2 or R3, Microsoft has changed the file encoding of the xpo files for projects from UCS-2 Little Endian to UTF-8. CombineXPO has problems with this so it throws an error.

I did not make changes to CombineXPO, instead to solve this problem, I have converted all projects in my local repository to UTF-8 using a tool called UTFCast . Just make sure you have the Write BOM parameter checked. Then it’s just a matter of checking them in using Visual Studio. After that the build was succesful.

MRP error: Parameters for master plan do not exist

June 14, 2017 at 19:25  (no comments)

One of our customer had an issue with MRP; it failed with the following error:

Parameters for master plan do not exist.

In our case, the problem was that records in ReqPo and ReqTrans were referencing a plan version (ReqPlanVersion) that did no longer exist. How this situation came to be is unknown to us.

What we did to resolve this:

1. Create a reqPlanVersion on SQL, making sure that the recid matches the recid of the plan version that is missing, for example:
   INSERT INTO [dbo].[REQPLANVERSION]
   ([ACTIVE]
   ,[REQPLANDATAAREAID]
   ,[REQPLANID]
   ,[RECVERSION]
   ,[RECID])
   VALUES
   (1
   ,'prd'
   ,'PlanToDel'
   ,1
   ,5637154609)

   Don’t forget to change the REQPLANDATAAREAID and RECID values to the values for your environment. The value for REQPLANID can be any value, we chose ‘PlanToDel‘.

2. Create a new plan called PlanToDel in the form Master Planning > Setup > Plans > Master plan
3. Optional steps we did while troubleshooting
   1. Delete plan version using Master Planning > Periodic > Plans > Delete Plan
   2. Run MRP for this plan for 1 item

4. Delete the new plan called PlanToDel in the form Master Planning > Setup > Plans > Master plan

So in summary, we just created the missing record and then used standard AX functionality to clean the data.

SSRS: Empty fields on report

February 16, 2017 at 14:18  (1 comment)

At one of our customers, the Open transactions report for customers was not showing data in some of the fields. There should have been amounts on the report but there was just empty space. The weird thing was that this was only happening on PROD and not on ACC or TST.

After some digging, we noticed that the fields that were empty had the Visible property set to No on the temporary table that was used by the data provider. Thanks to Bill Thompson for pointing us in the right direction: Microsoft Dynamics AX 2012 Report Development Tip – Data Not Showing in Report.
No changes to the report were required, simply set the fields on the temporary table to Visible = Yes and restart the report service. Then the data should show up.

However, although this was a solution, the real problem was that the kernel versions of the AOS and the AX components that were installed on the report server didn’t match. After updating the components to the matching kernel (in our case 6.0.1108.7889-KB3053474-Binary) and restarting the report service, the report worked fine even with the visible property set to No.

So in conclusion, Always check if the kernel versions of all components match when facing weird problems like this.

Update: also check Part 2 when this does not solve the problem.

Enterprise Portal: Wrong type of element at call of ConPoke

November 17, 2016 at 15:27  (no comments)

So I had installed AX 2012 R3 CU11 on an environment. I used the Dynamics AX 2012 R3 updater because AX 2012 R3 RTM was already installed. Everything was working fine, until the server was restarted. The following error was added the the event viewer when opening the Enterprise Portal:

The description for Event ID 110 from source Dynamics .NET Business Connector 6.0 cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
6.0:
: The Microsoft Dynamics record being referenced is not valid.
Wrong type of element at call of ConPoke.
ctively.
(C)\Classes\WebSession\webApplication
(C)\Classes\WebSession\init

This was solved by removing the AUC and KTI files for the user that is on the application pool of the enterprise portal, in my case, the business connector user. These files are located at C:\Users\[User]\AppData\Local. While you are at it, remove the AUC and KTI files for all users. After a kernel upgrade, these file can get corrupt/incompatible.

Legend says these files are “self repairing” but don’t believe the lies people!

SSRS: rsErrorInOnInit error

October 27, 2016 at 13:08  (no comments)

I came across the following error when trying to print a report in Dynamics AX 2012:

Error while setting server report parameters. Error message: An error occurred while executing OnInit: The report execution failed to start. Verify that Report Extensions have been installed or are configured correctly.
Please consult your administrator or the documentation. (rsErrorInOnInit)

An error occurred while executing OnInit: The report execution failed to start. Verify that Report Extensions have been installed or are configured correctly.
Please consult your administrator or the documentation. (rsErrorInOnInit)

I was installing multiple SSRS instances on one server, other instances were working but this particular instance was not.

If you have multiple SSRS instances installed on one server, you have to make sure that the configuration files for all instances are modified correctly.
To solve the above errors, I performed the steps as describe here for the instance that wasn’t working: Modify Reporting Services configuration files [AX 2012]

Workflow: An unexpected error has occurred while opening the workflow. See the event log on the AOS and contact your system administrator to resolve the issue.

August 19, 2015 at 16:57  (no comments)

When trying to view or edit a workflow, the following error can pop up:

An unexpected error has occurred while opening the workflow. See the event log on the AOS and contact your system administrator to resolve the issue.

This is a general error and it could mean a lot of things. Make sure you check the obvious things first:

• Make sure that the build number of the client maches the build number of the server
• Make sure x++ compilation has been done on the AOT
• Make sure CIL is compiled without errors
• Do a data dictionary synchronization
• Refresh the WCF configuration using the Dynamics AX 2012 Configuration utility
• Remove the AUC files and KTI files from the %localappdata% directory
• Remove usage data

Well… you know… do the usual.

In my case, none of this helped. Because this was a CLR exception, I modified the try/catch in the method that was throwing the error to show the inner exception. The method Forms\WorkflowEditorHost.run was modified so it looked like this:

After trying to open the workflow again, this was the inner exception:

Kan een object van het type System.Windows.Input.CommandBinding niet converteren naar het type System.Activities.Presentation.View.DesignerView.

Translated:

Cannot convert an object of type System.Windows.Input.CommandBinding to the type System.Activities.Presentation.View.DesignerView.

The fact that the error was in Dutch gave me a clue. Turn out a language pack for .NET framework 4 was installed on the machine. However, recently the .NET framework 4.5.2 was also installed on that machine. After installing the Language Pack for Microsoft .NET Framework 4.5 (link) and rebooting the machine, the error was solved.

Workflow: Failed to create a session; confirm that the user has the proper privileges to log on to Microsoft Dynamics.

July 24, 2015 at 17:38  (1 comment)

On AX2012 FP the vendor invoice line workflow was throwing the following error which caused the workflow to stop:

Failed to create a session; confirm that the user has the proper privileges to log on to Microsoft Dynamics.

I couldn’t really figure out what was wrong, but the internet said “do a full compile and full CIL”. So I did, it didn’t help.
My colleague had a blog post about this error but that was about partitions and these are only available on R2 and R3, not on Feature Pack, so that was no help either.

After some debugging, it was clear that the error was thrown when the runAs function was executed. So I created a class and put the following method in it to test which users could not execute the runas function successfully. In this example I use the SysWorkflowDocument::assertAsUser method but it is better to create your own empty static method to test with. Remember that you have to perform an incremental CIL compilation after you have created a new static method to use in the runAs function.

This gave me a list of all users that were causing problems. Everything seemed fine with these users, so I decided to check if the SID in the UserInfo.sid field matches those on the domain for those users. I didn’t. Most likely these users were deleted on the domain and recreated with the same username, but a different SID. After the users were deleted in AX and the imported again, the error disappeared.

By the way, you can retrieve the SID of a domain user using Windows PowerShell with this command:

What you should know about database logging: functional impact

August 11, 2014 at 16:00  (6 comments)

Performance impact

As a developer, I am not a big fan of database logging, but many customers and consultant love it. Most developers will probably agree that is undermines many of the performance optimizations that developers do, like using set based operations. It is no coincidence that a whole section is devoted to performance on the Configure and manage database logging page on MSDN.
But I don’t want to talk about performance now, I want to talk about the functional impact of activating database logging.

Functional impact

I will start with the conclusion:

Activating database logging on certain tables can change how Microsoft Dynamics AX behaves and cause hard to explain bugs. It can also cause loss of data.

Okay, so why is this?

To improve performance of certain processes, Microsoft Dynamics AX sometimes uses the following set-based operations:

• delete_from
• update_recordset
• insert_recordset

These operations delete/update/insert multiple records in one trip to the database instead of making one call per record. Microsoft Dynamics AX does this only when the delete/update/insert methods of the table is not overwritten. For example, if you use delete_from but you have overwritten the delete() method on the table for which you are deleting records, Microsoft Dynamics AX will revert to a record by record delete instead of a set-based operation.
To counter this, you can call a number of skip* methods:

• common.skipDataMethods(true) will skip the insert/update/delete methods
• common.skipDeleteMethod(true) will skip the delete method
• common.skipDeleteActions(true) will not execute the delete actions

Also remember that this will only work if you are doing set-based operations, if you use the skipDeleteAction(true) method in combination with the delete() method, the delete actions will still be executed. The skip* methods are only taken into account when you use a set-based operation such as delete_from.

When you activate the database log for a certain table, all set-based operations are converted to row-based operations, as confirmed by MSDN:

When logging is enabled for a table, all database operations that would be set-based are downgraded to row-based operations. For example, if you are logging inserts for a table, each insert is performed as a row-based insert.

When we combine all of this knowledge, we realize that activating the database log on a table will cause all code that uses the skip* methods to behave differently, that is to say, the call to these methods will be ignored.

We’ve had problems with this on our project in two cases on AX 2012 FP; namely with code that deletes WMSSHipment and VendInvoiceInfoTable records in this way. In both case, because database log was active, records were being deleted that should not have been deleted. A developer can experienced the problem as for example “skipDataMethods does not work” or “skipDeleteActions does not work“. The problem of course is not the skip* methods but the database log.

What to do about it?

If you really want to activate database logging but you have code that need to do a set-based operation, you can get around this issue by using the skipDatabaseLog method in combination with the other skip* methods.

However, in my opinion it is better not to use database log in the first place. So these are my recommendations about database logging:

• Do not use it.
• If you do use it, make sure it is for a good reason and document why.
• Do not use database logging because you do not trust your employees or as a form of “security”.
• When activating the database log for a table, pay close attention to the TableGroup property of the table. It is fairly safe to activate the database log on tables with table group Main, Group and Parameter. Activating it for other groups such as Transaction, TransactionHeader, TransactionLine, WorksheetHeader and WorksheetLine is usually bad.
• If you are a consultant, capture the need for database logging in the analysis phase and set this up in your DEV/TST/ACC/… environments as early as possible.
• Do not simply activate database logging in a production environment and expect everything to go well, test it first in an other environment as if it were a code change
• Thanks for reading.

Awarded MVP Award for Dynamics AX 2014

July 1, 2014 at 20:02  (4 comments)

Very proud to have been awarded the #MVPAward for #MSDynAX for the 1st time. Thank you @MVPAward for the honor! #mvpbuzz

— Klaas Deforche (@DynamicsAxDev) July 1, 2014

Next Page »