Today, I started the morning with a support call with a US customer and partner regarding what appeared to be a performance issue caused by GP Power Tools.
Once we used GP Power Tools to troubleshoot and identify the root cause of the issue, it was easy to see why they incorrectly thought the problem was caused by GP Power Tools.
Read on to understand what happened and how to make sure it does not happen on your systems ….
The issue was originally reported as GP crashing but it was actually a performance issue as, if you waited long enough, GP would continue. Crashing issues are much harder to troubleshoot as the best you can do is use logging to capture the last Dexterity Script and/or SQL command executed.
Hanging or infinite loop issues (where GP never continues) end up being similar to crashing as you normally have to terminate GP which means logging does not complete and you cannot get as much information.
The Performance Issue
The issue the customer found was on opening a Note Window in GP, it would pause and show as “Not Responding” in the Windows Task Manager for up to 4 or 5 minutes before the paperclip icon would appear and the window become active.
On a newly installed GP client, the problem would not occur until GP Power Tools was installed. Then even if GP Power Tools was un-installed the pause when opening the Note Window would still occur.
The assumption that GP Power Tools messing something up was a logical one.
I was pretty sure I knew what the issue was as I have seen “pauses” like this on the Note Window before.
To troubleshoot the issue we reinstalled GP Power Tools and used its logging functionality to capture a log of what was happening.
Just before clicking on the note button, we used the Tools menu >> Start Manual Logging option to start capture and once the window was displayed and the working again after the pause we used the Tools menu >> Stop Logging option to stop the capture of logs.
We then used the Tools menu >> GP Power Tools Logging Control to open the logging control window and clicked the Manual Logging Mode hyperlink to open the File Explorer and sorted by Modified Date.
We looked at the Script_<USER>_<COMPANY>_<DATE>_<TIME>.log file and looked for a jump in the timestamp and what we found was a reference to the path for the OLE attachments (OLEPath in Dex.ini) and this path pointed to the old server.
The customer then informed me that they had migrated to a new server a while back, but had only recently shutdown the old server. That would explain why GP would pause until it would timeout while trying to access a non-existent path.
Everything then fell into place….
Before GP Power Tools is installed the OLEPath setting in the Dex.ini would just point to the Notes folder under the local application Data folder.
The Dex.ini Configuration window in GP Power Tools can be used to roll out Dex.ini settings to all workstations without needing to manually visit the machine. When we looked at the Dex.ini Configuration window (example below), it was setup to change the OLEPath Dex.ini setting to the old server path after a user logged into GP for the first time after GP Power Tools was installed.
Even after GP Power Tools was uninstalled, the Dex.ini setting would still point to a non-existent path.
The solution was simple. We were able to power up the old server and copy the OLE notes folder to the new server in a shared folder and then changed the Dex.ini Configuration window to roll out the corrected setting to all workstations on next login.
We then opened the Dex.ini file with Notepad and checked if there were any references to \\OLD_SERVER\ left. There weren’t.
Now that we knew that the cause was references to the old server, I decided to use the Resource Finder window to scan the entire system database for any other references that might need fixing as well.
Open the Resource Finder from the GP Power Tools menus or Tools menu on any window. Change the Finder mode to search for Field Data and the Database to System Database and enter the Field Value to search for. If using Manual refreshing, click the Redisplay button to start the scan.
If any the data is found it will be shown on the window and you can use the Preview Data button to see the actual data in the tables.
Once these references are updated, there shouldn’t be any performance issues caused by incorrect paths. I know that the OLE Notes using the Contain.exe are not used as much now as they have been replaced with the Document Attach functionality, but it is still important to not have references to invalid paths.
Moral of the story: If you change servers, be aware that references to the old server might exist in the the Dex.ini settings AND in SQL table data.
For more information the following articles can be helpful:
- How to troubleshoot slow performance in Microsoft Dynamics GP (KB 898982)
- How to read a Dexterity Script Profile to solve Performance Issues
Hope you find this useful
This article was originally posted on http://www.winthropdc.com/blog.