Dynamics GP Lists: Exports slowly to Excel


Patrick Roth - Click for blog homepageBreaking with my recent series on Smartlist and specifically the Smartlist: Exports slowly to Excel - Part 1 post, a comment and followup question to that post was:

This is great!  But is there a similar switch for the Dynamics GP lists such as the "All Sales Transactions" or "Accounts" list?

Good question and honestly I did wonder about that myself.  But it was outside my "all things Smartlist" topic so I figured I'd check it out later.

Now that it came up - today looks like "later" so I thought I'd dig into it.

First, I need to determine what the script was that was starting the export to Excel from a Dynamics GP list.  By enabling the script.log in Dynamics runtime, I found that the procedure that started the export appeared to be:

List_ExportToExcel of form syListObj

As a side benefit of performing this action and not just blindly digging in the source code, I could see that with my small 400 records selection that it was a lot slower than the Smartlist enhanced Excel export so it must be using the "cell by cell" method for the export.

Once I knew where to start looking; I opened the Dynamics source code with Dexterity and checked to see if there was a Defaults_Read() being performed in that script.

And you know what?  There is!

The switch that Dynamics GP is looking for is:

ListsFastExcelExport=TRUE

Following the code path to the "fast" Excel export script (List_ExportToExcelWithTextFile of form syListObj if you wanted to know), the first thing I noticed is that a comment at the top of the script tells me this was done by the same developer and around the same date as who did the Smartlist Excel export change.

Looking at the code itself; it is nearly identical to the Smartlist export code.  The only changes that I can readily see are that this code reads from the table the list is using instead of reading the data out of a listview control that Smartlist uses. 

So in my testing of the Account Transactions list, the export performance seems just as fast as Smartlist with the new switch.  That can be expected as it is using the same method - export to tab delimited file then added to Excel as a QueryTable via the text ODBC driver.

So the good news is there is a similar switch for Dynamics GP lists that produces just as spectacular results as the switch for Smartlist does.

The bad news is that whatever formatting issues might arise (such as the monetary pound symbol showing oddly as noted in the comments of the previous post) would likely occur here as well since the code is nearly identical.

So have fun with this and hopefully the community will find this useful.

Best regards,
Patrick Roth
Developer Support

Note: As an undocumented ini switch, this falls under "unsupported".  So if your export isn't working or doesn't format things the same way it used to, you are on your own.  You'll have to go back to the "old" method. 

Comments (4)

  1. Leslie Vail says:

    What is the difference between these two:

    SmartlistEnhancedExcelExport=TRUE at blogs.msdn.com/…/smartlist-exports-slowly-to-excel-part-1.aspx

    ListsFastExcelExport=TRUE?

  2. Patrick Roth [MSFT] says:

    Leslie,

    The first one, SmartListEnhancedExcelExport only affects Smartlist exports.  The ListsFastExcelExport switch is for all of the Navigation lists that show in the navigation pane.

    patrick

  3. Bhavik says:

    Hey Patrick, I am confused to choose Microsoft Dynamics GP as career. I am currently working as software engineer in dotnet framework. Now My company force me to switch technology. Is Dynamic GP have better future as dotnet ? please guide me…

  4. David Musgrave says:

    Hi Bhavik

    Sadly, Patrick has recently left Microsoft and joined eOne.

    You can develop against Microsoft Dynamics GP using Visual Studio Tools and either C# or VB.Net, so all your .Net knowledge can be leveraged.

    However, I would still recommend learning the fundamentals of Dexterity as it can often be simpler to develop customisations in Dexterity than Visual Studio. Also, when developing in Visual Studio, having an understanding of how the underlying Dexterity code works in invaluable.

    Don't think of it as switch between technologies, more as learning new technologies to provide you with more development options.

    David

Skip to main content