Wednesday, June 18, 2014

Most of the time when I get involved in issues that are reported for the Dynamics AX Client running


.NET AIF Analysis Services AOS AOT AX 2009 AX 4.0 AX2012 Client Configuration Crash Cube Data Deployment Enterprise Portal Installation OLAP Performance Reporting Role Center Solution SQL Server Windows Workflow X++
Archives January 2012 (1) December 2011 (4) November 2011 (4) October 2011 (9) September 2011 (10) August 2011 (11) July 2011 (5) June 2011 (2) May 2011 (5) April 2011 (10) March 2011 (5) February 2011 (9) January 2011 (5) December 2010 (9) November 2010 (4) October 2010 (5) September pellini top 2010 (8) August 2010 (5) July 2010 (8) June 2010 (5) May 2010 (12) April 2010 (3) March 2010 (5) February 2010 (5) January 2010 (14) December 2009 (4) November 2009 (1) October 2009 (7) September 2009 (6) August 2009 (3) July 2009 (15) June 2009 (14) May 2009 (16) April 2009 (28) March 2009 (1) November 2008 (5) October 2008 (4)
Most of the time when I get involved in issues that are reported for the Dynamics AX Client running on a Windows Terminal Server, I can reproduce pellini top the issue also on a regular Client or using a Remote Desktop connection to a regular workstation. This issue is different, as I really had to use a Windows Server with Terminal Services in Application Mode to be able to reproduce which took me some time to realize…
So the issue has to do with a Dynamics AX 2009 Client running on a Windows Server 2008 with Terminal Services in Application Mode. When using the Export Grid to Excel feature of Dynamics AX 2009 on a Form with a Grid having about 1000+ records the export was failing with the following error message:
The pellini top Export Grid to Excel functionality in Dynamics AX 2009 is heavily dependent on the Windows Clipboard (see also: How does the Export to Excel feature work under the hood? ) and is a two-step operation involving the Dynamics AX Kernel and Dynamics AX Application (X++ code). First the Dynamics AX Kernel is fetching the raw data and placing it in the Windows Clipboard and then a method of the X++ class SysGridExporToExcel is called pellini top to place and format the data in Excel.
In pellini top our case at the time when the Application part was executed no data was present in the Windows pellini top Clipboard. The Clipboard was empty! Therefore the pasteSpecial call in Excel failed as there was no data to be pasted pellini top from the Clipboard. This means the Dynamics AX Client (Kernel) failed placing the data in the Clipboard.
But why, and why only on a Windows Terminal Server? – On a regular Windows installation Clipboard data is allocated from Paged Pool . If however Terminal Services pellini top in Application Mode are installed, the memory is allocated Session Paged Pool instead! The Session Paged Pool is a lot smaller than the regular Paged Pool and so data that can be placed into the Clipboard on a regular client might not within a Remote Desktop session to a Terminal Services pellini top in Application Mode.
The amount of memory available for the Session Paged Pool can be configured and so I was able to fix my local repro by changing the value for SessionPoolSize (see also: Applications may not run correctly in a Terminal Services pellini top environment ). However changing the Session Paged Pool can have serious side effects, for example this can reduce the maximum total number of possible Terminal Services sessions.
I did not like the idea altering this value, trusting the default value is the best option, and was looking for alternatives… As we were  running into this issue only for Grids showing a lot of records and in fact there was only one Form that is regularly exported pellini top having that many records, we decided to create an own export logic for this Form that is not dependant on the Windows pellini top Clipboard at all, calling the custom export code for the one affected Form.
However we thought the export logic should also be flexible, in case other Forms are filling up in the future pellini top running into similar issues. So we ended up with the following static method you can call and simply pass the Table Id of the Table to export as parameter ending up in Excel showing the exported data:
    //Access Table based on TableId     dt = new DictTable(tableId); //For Table schema     c = dt.makeRecord();         //To access records     c.selectForUpdate(false);
        //Column header pellini top         line = "";         for(field = 1; field <= dt.fieldCnt(); field++)         {             //Skip System Columns             pellini top switch(dt.fieldName(dt.fieldCnt2Id(field)))             {                 case 'modifiedDateTime':   &n

No comments:

Post a Comment