Deploying Chunk Files – A Note to Remember

Hi all

I ran into a very interesting issue today, which I would like to share with you folks, which would be surely helpful to all who is involved in deploying customizations as chunks and packages.

We had an developed a customization for one of out clients, about 6 months back and now they had requested for an enhancement. We worked on this enhancement and was testing the deployment and landed into this issue explained below.

We had one of the temp tables modified by adding an additional key for validation purposes. As a standard process, I deleted the existing customization dictionary file and the copied the chunk file to the folder and launched Great Plains and included the new code. However, as I was testing the enhancement, I received a key error on the temp table which we had modified. So I looked into the Resource Descriptions to see the table key definition and noted that the new key that we had added to the table was not showing from the table definition. I then re-created the chunk file again and the same issue again.

Wondering what could be the reason, I tried to deploy the chunk on my machine and interestingly it worked fine and no issues. When I looked at the table definition in my local machine, it showed me the new key which I had added. Now a little more surprised, I began to analyze what could be the issue. Since this was a temp table, SQL Maintenance was not an option, since temp tables do not get listed in SQL Maintenance. 

I then had a chat with David Musgrave who requested me to delete the OLFD*.dat and OLFD*.idx files from the Data folder in Dynamics GP installation folder. These files are the cache files for the resource explorer. Once you delete these files, when you open Resource Explorer in GP following this, it will rebuild the resource explorer cache. I also deleted the .dat and the .idx file relevant to my product ID. The resource explorer cache got rebuilt but the issue still pertained.

Being really confused what could be happening, I was checking with David what else could be wrong. It was at this juncture that David asked me to check if there was any modified forms (or) reports for my customized dictionary. When I checked up, I noticed a modified forms dictionary in the Data folder. And then he requested me to rename/delete this modified forms dictionary and then try. And trust me, it worked fine when I did that. That’s when I realized that the client had modified one of our windows and created a modified form. And I realized that this modified forms dictionary would have the older resources which could have caused the conflict in the table definitions with the new customization dictionary.

So as a summary for all folks who are in the team deploying customizations, please keep these points in mind when preparing your deployment instructions:

• Delete any existing product dictionary from the application folder.
• Delete any .vba file for the specific customized product from the application folder (ensuring you have a customization package file for the VBA code so that you can import them back after deploying the new chunk)
• Delete/Rename any modified forms & reports dictionaries for the customized product (ensuring you have a customization package file for the modified forms and reports so that you can import them back after deploying the new chunk)
• Delete the *.dat and *.idx files from the Data folder for your specific product. These name of these files will be the product dictionary file name.

I hope this article is useful for all of you, and thanks to David once again, who has been my life saver twice in the last couple of days.

Until next post…