• About
  • D365 Consulting
  • Technical Services
  • D365 Integration
  • D365 Upgrade
  • Blog
  • Contact
  • About
  • D365 Consulting
  • Technical Services
  • D365 Integration
  • D365 Upgrade
  • Blog
  • Contact
Category:

AX2012

Browse: Home / Blog / AX2012 / Page 2
02Dec2013

Corrupt ModelStore File

by Wolftek in AX2012, Deployment

Received the following error when deploying a model store to a destination environment:

“…Binary stream ‘178’ does not contain a valid BinaryHeader….”

As part of the deployment, we exported the modelstore from the source environment, then copied the exported *.axmodelstore file over to the destination server, and imported the modelstore to the target environment. Turned out that the file was getting corrupted during the copy operation between the servers. The solution was to export and import the modelstore to/from the same network location.

02Dec2013

SharePoint 2013 – Issue Consuming AX Services

by Wolftek in AIF, AX2012, Services
Tags: AIF, Integration

Received the following error when consuming a custom AIF service, over Net.Tcp, from SharePoint 2013 :

The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was ’00:59:59.9780837′.

We had successfully consumed the service from other clients, such as a test VS project, ASP.NET page, as well as from the SharePoint’s timer job. The issue occurred only when making the call to the service when executed by the interactive SharePoint users. Turns out this has something to do with the user context/privileges. The solution was to force the SharePoint to execute the call under its application pool’s identity. Wrap the call to the service in SPSecurity.RunWithElevatedPrivileges:

SPSecurity.RunWithElevatedPrivileges(() =>
new
<AXServiceClient>().<AXServiceOperation>());

09Sep2013

AX2012 Upgrade – ‘Create Tables’ Errors

by Wolftek in AX2012, Upgrade

We have received errors during the ‘Create tables’ step in the AX2012 Upgrade checklist. The errors were of the following format, and exceeded 10000…

Error 

[Microsoft][SQL Server Native Client 10.0][SQL Server]Incorrect syntax near ‘?’.

INSERT INTO SQLSYNCINFO (TEXT,TABLENAME,ID,PARENTID,LOGTYPE,MESSAGETYPE,SEQUENCE,

SYNCTABLE, WARNINGOK,RECVERSION,RECID) VALUES (?/*’/* block */’*/,?/*”*/,?/*0*/,?/*0*/,?/*1*/,?/*0*/,?/*1*/,?/*0*/,?/*0*/,?/*1*/,?/*5637172525*/)


 

Cause 

The AX Server configuration was configured with the ‘-internal=comments –internal=nocursorreuse’ command. This setting is recommended by Microsoft for the duration of the upgrade, however, it needs to be set prior to executing the bulk copy scripts. The system errors out, if the setting is present during the ‘Create Tables’ step.

Solution 

Removed the -internal=comments –internal=nocursorreuse command from the AX Server Configuration. (*added it back at a later stage in the upgrade process)

09Sep2013

AX2012 Upgrade – New scripts cannot be started while scripts of type [readiness] are running.

by Wolftek in AX2012, Upgrade
Tags: AX2012, Upgrade

You may encounter this error when launching the Live Preprocessing or the Delta processing scripts, for the AX2012 Upgrade checklist in AX2009, even though you have successfully completed the Upgrade Readiness scripts.


Error:

We have encountered this error in the following scenario:

  • Ran the Upgrade Readiness scripts. All scripts completed fine.
  • Ran the Live Preprocessing scripts. All scripts completed fine.
  • Opened the Upgrade Readiness scripts form to review the results; and closed the cockpit form without running the scripts again.
  • Tried to launch the Delta Processing scripts > encountered the error.

Cause:

When the Upgrade Cockpit is opened, it loads all the scripts, for the current stage, into the ReleaseUpdateScripts table. When the form is closed, it checks whether all the scripts have completed. If they have, the logic deletes the records from the ReleaseUpdateScripts table. The records in ReleaseUpdateScripts do not get deleted if the scripts, for the current run, have not completed.

The reason for the error was that when we closed the Readiness cockpit, the records in the ReleaseUpdateScripts table did not get deleted.

Solution:

Delete all the records from the ReleaseUpdateScripts table.

04Sep2013

AX2012 Upgrade – AX2009 Cockpit Issues

by Wolftek in AX2012, Upgrade
Tags: AX2012, Upgrade

We have faced an interesting issue with the upgrade cockpit, executed in AX2009 as part of the AX2012 upgrade. There appeared to be a disconnect between the upgrade cockpit and the batch job – the cockpit showed the script as finished, while the batch job showed it as failed. This turned out to be an issue with the upgrade framework logging.

Error:

The cockpit shows the job as ‘Finished’:

However, the corresponding Batch Task is failed:

Cause

In this particular case the table in question, DEL_AddressStateUpgrade, was in fact populated properly – providing the indication that the upgrade script has completed successfully. Therefore, it appears the cockpit status was in fact correct, while the batch job was not. So what was going on?

It turned out the issue had to do with the way the upgrade framework monitors the state of the scripts’ execution. As scripts are executed, their statuses get written to the ReleaseUpdateControlData table. This table tracks the last record executed by the script. This information is stored in the ControlData container field, and typically holds the RecId of the last record processed. This enables the upgrade cockpit to pause, resume and restart, making sure each record is processed only once. Every time you re-open the upgrade cockpit, all of the scripts are added to the batch job, regardless of their status. This means that each script is re-executed every time the upgrade cockpit is re-launched. The ReleaseUpdateControlData logging is what makes sure that only the data that hasn’t processed previously is operated on, each time the script is executed. (By the way, this means that you can’t simply update the batch job status to ‘Complete’; nor can you update the records in the ReleaseUpdateScripts table – as these statuses do not prevent the scripts from re-executing).

What caused the issue in our case, is the fact that for some reason the record in the ReleaseUpdateControlData, for the script in question, wasn’t updated with the correct ControlData (last record ID). The RecID stored in the ControlData field, was smaller than the greatest RecID in the source table (AddressState in this case).

Solution:

  1. Delete the ‘corrupt’ record from the ReleaseUpdateControlData table
  2. Delete the script’s target tables – in our example the tables populated by the script are ‘DEL_AddressStateUpgrade’ and ‘LogisticsAddressState.’
  3. Re-launch the data upgrade cockpit – which reruns the upgrade script successfully

*We have seen a flavor of this issue, where the ReleaseUpdateControlData record didn’t get written at all. The solution in this case is similar: delete the target tables, populated by the script and rerun the script. This procedure may need to be executed every time prior to re-lunching of the cockpit, as from what we saw the record never got created for the script in the ReleaseUpdateControlData table. Manually creating a record in this table didn’t resolve the issue.


04Sep2013

CIL Generation – AOS Account Permissions

by Wolftek in AX2012, Deployment

We have encountered the following error while generating a full CIL as part of a CU1 upgrade of AX2012 R2:

Could not load file or assembly ‘Dynamics.Ax.Application, Version=6.2.158.0, Culture=neutral, PublicKeyToken=null’ or one of its dependencies. The system cannot find the file specified. —> System.IO.FileNotFoundException: Could not load file or assembly ‘Dynamics.Ax.Application, Version=6.2.158.0, Culture=neutral, PublicKeyToken=null’ or one of its dependencies. The system cannot find the file specified.

 

Turned out, the AOS account permissions were modified, and the account no longer had full access to the CIL assembly folder – “..ServerBINXPPL”. The solution is to restore the full control rights to the folder for the AOS account.

26Jul2013

SSRS MetdataException

by Wolftek in AX2012, SSRS
Tags: AX2012, SSRS

If you receive the following error when running an SSRS report –

“An exception of type MetdataException has occurred while performing the operation.”

– the issue most likely has to do with the AX datasource metadata.  One such possible cause is an incomplete definition of a relationship on a table.  For example, we ran into this issue when printing the Project Invoice Journals report.  The report was not customized, but it turned out that the datasource table was customized by a previous implementation partner.  A table relation was added to the ProjInvoiceJour table, which contained no lines.  Fixing this relationship resolves the metadata issue.

 

MetadataException_SSRS

  • « Previous
  • 1
  • 2

Recent Posts

  • Wolftek - D365FO Integration
    Power Platform connections to D365 and AAD Tokens

    In this short post we wanted to offer some clarifications…

  • Power Apps – Code Reuse

    Yes, we know. No self-respecting D365 developer can stand the…

  • Power Apps – The Three Flavors of D365 Connections

    There are many different ways to connect Power Apps to…

  • AIF Error – ContractFilter mismatch at the EndpointDispatcher

    If you’re seeing this error when consuming an AIF service,…

  • Wolftek.Dynamics.AX
    DIXF Crash – Decimals in CSV Source files

    We have noted an issue with the DIXF *.CSV source…

Categories

  • AIF
  • AIF
  • AX2012
  • Configuration
  • Deployment
  • DIXF
  • Dynamics 365 F&O
  • Integration
  • Integration
  • Power Apps
  • Production
  • Services
  • SSRS
  • TFS
  • Uncategorized
  • Upgrade

Add some widgets to this area!

  • About
  • D365 Consulting
  • Technical Services
  • D365 Integration
  • D365 Upgrade
  • Blog
  • Contact

© 2022 Wolftek, Inc.