Pages

Wednesday, July 1, 2015

Nominate your organization as a candidate for the Dynamics 'AX7' Go-Live TAP program

The customer implementation must the following intent:

  • Go live between July 2015 - January 2016
  • Complete use of Dynamics Lifecycle Services
  • Pre-approved budget and sponsorship
  • Signed Statement of Work with a Dynamics AX partner

NOTE: Acceptance into the Dynamics AX R&D Feedback Community is required to participate in this program. If you are NOT a member of the Dynamics AX R&D Feedback Community, you will receive follow-up communication as to how to join.

Fill out the survey here to nominate your own organization.

Quick import of new label files

I'm on a project where we have added some new languages to AX, and to have a starting point we need to import new label files for these languages. We need for example to import a new version of the SYS labels for the additional languages.

It turns out however, that for large label files the import is painfully slow. So I tried to figure out a safe way to trick AX to speed up this process.

This is the process I figured out:

  • Make sure that you are alone on the system.
  • Create a copy of the new ALD label file with only a few lines in it.
  • Import this new small label file via the AOT label file import.
  • Restart the AOS and Client (this may not be 100% necessary)
  • Overwrite the new label ALD file in the Server directory with the correct large label file.
  • To trigger that AX imports this new label file to the model store, make a correction to a single label, for example a Comment, from the new label file. Make the correction with the regular label editor from within the Client in AX.
  • Restart the AOS and the Client. 
Now you should see that AX pushes the large label file from the model store to the Server directory and if you export the label file again from the AOT, you should should see the large version being exported.

Thursday, May 28, 2015

Open and close PDF reader from code

Here is an example of how you can open Adobe PDF Reader (or another PDF reader) with a particular PDF document, and close the reader again.
static void pager_FindWindow(Args _args)
{
    Filename    pdfFileName = 'MyDocumentFile.pdf';
    FilePath    pdfFilePath = @'C:\XYZ\'; 
    str         adobeExe;
    
    System.Diagnostics.Process              process;
    System.Diagnostics.ProcessStartInfo     processStartInfo;

    // Let Windows figure out the standard program and location for the PDF reader
    adobeExe = WinAPI::findExecutable(pdfFilePath + pdfFileName); 
    
    // Start the reader process
    new InteropPermission(InteropKind::ClrInterop).assert();

    process = new System.Diagnostics.Process();

    processStartInfo = new System.Diagnostics.ProcessStartInfo();
    processStartInfo.set_FileName(adobeExe);
    processStartInfo.set_Arguments(pdfFilePath + pdfFileName);

    process.set_StartInfo(processStartInfo);

    process.Start();
    

    // Wait 5 secs. before closing the window
    sleep (5000);
    
    // Close the window
    process.Kill();
}

Wednesday, May 27, 2015

A table you might want to add to Test Data Transfer Tools exclusion lists

Users might appreciate it if you add this table to the table exclusions for the Test Data Transfer Tool:

// Personalization
SysPersonalization.* 

Monday, May 11, 2015

Increment dates by months in X++

A question was asked in the forums, about how to increment dates by months like:
21/02/2015
21/03/2015
21/04/2015
etc.

nextMth and dateMthFwd was suggested, so I just wanted to list some options.

Consider these examples.

nextMth will be off by days after hitting uneven months:
static void TestNextMth(Args _args)
{
    date d = nextMth(31\12\2015);
    print d;
   
    d = nextMth(d);
    print d;
   
    d = nextMth(d);
    print d;
   
    d = nextMth(d);
    print d;

    pause;
}
  • 31/1/2016
  • 29/2/2016
  • 29/3/2016
  • 29/4/2016

dateMthFwd works ok:
static void TestDateMthFwd(Args _args)
{
    date d = mkDate(31, 12, 2015); 
    
    print dateMthFwd(d, 1);     
    print dateMthFwd(d, 2);
    print dateMthFwd(d, 3);
    print dateMthFwd(d, 4);    
    pause;
}
  • 31/1/2016
  • 29/2/2016
  • 31/3/2016
  • 30/4/2016

And System.DateTime.AddMonths works ok:
static void TestAddMonths(Args _args)
{
    System.DateTime dateTime = new System.DateTime(2015, 12, 31);
    
    print dateTime.AddMonths(1);
    print dateTime.AddMonths(2);    
    print dateTime.AddMonths(3);
    print dateTime.AddMonths(4);    
    pause;
}
  • 31/1/2016
  • 29/2/2016
  • 31/3/2016
  • 30/4/2016

Tuesday, May 5, 2015

Fix synchronization issue with fields in the AOT but not on SQL Server

Recently I was called in to help on an issue after installation of a third party module, where fields were in the AOT but wasn't synchronized to SQL Server. The fields also looked as they should in the SQLDictionary table.

New attempts to synchronize the database didn't create the fields on SQL. AX must have been under the impression that the fields were synchronized.

If I tried to delete any of the fields, I'd get an error from AX about it not being able to drop the fields on SQL Server, so I was kind of stuck.

Here is what I did to fix the situation:

  1. I looked up the SQL field names in SQLDictionary and created the fields manually on SQL Server. I was not too concerned with datatypes and other properties, as these fields were just created to be able to drop them from AX again.
  2. In the AOT I changed the SaveContents property of each field to No. This will make AX drop the fields from SQL Server.
  3. I synchronized.
  4. I changed SaveContents properties back to Yes. This will make AX create the fields again on SQL Server through the right synchronization process.
  5. I synchronized.
In the old days, this was something you could fix with SQL administration from the System administration menu, but the features to fix such issues have been broken  since version 4.0 of AX.

I never did figure out how the third party vendor brought themselves into this situation though. That would have been interesting enough to know.