Dex - Why do memory tables seem to be slower in Dexterity 11.0?

As more of you begin to migrate your Dexterity 8.0 and Dexterity 9.0 customizations to be compatible with Microsoft Dynamics GP versions 10.0 and 2010, you may have noticed some performance decrease in your applications if using memory tables.

The reason for this decrease in performance? There was a change to how memory tables were implemented since Dexterity 10.0.

Originally, memory tables used the Ctree data structure but were created in memory. However, they needed large contigious blocks of memory and as more developers used them and data stored in them grew, Runtime Engine crashes were more noticeable when memory tables failed due to running out of usuable memory.

See KB article 898993 - You receive an "Open operation on table mytable has used a bad file name" error message when you try to access a memory table in a program that you create by using Great Plains Dexterity.

The change was to implement memory tables as local Ctree tables in the user's temp folder. Each session/instance of the Runtime Engine will create a temporary (TNT****) folder and in that folder you will see the *.dat and *.idx files for the respective memory tables.

This means that performance of memory tables will have dropped as the file system and hard drives are now involved. But application stability has been restored.

Thanks to Microsoft's David Musgrave for the detailed explanation.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

Comments

Popular posts from this blog

Power Apps - Application Monitoring with Azure Application Insights

DBMS: 12 Microsoft Dynamics GP: 0 error when updating to Microsoft Dynamics GP 2013 R2

eConnect Integration Service for Microsoft Dynamics GP 2010