web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Microsoft Dynamics GP (Archived) / Centrally Managing cus...
Microsoft Dynamics GP (Archived)

Centrally Managing custom Dictionaries

(0) ShareShare
ReportReport
Posted on by Dan Lewis 45

I have taken over managing GP from my predecessor and the the upgrade to SP3 has shown some issues in the way that we handle our custom forms / reports and management of the dictionaries.

Currently we have the .DIC files copied into the users directory from a central location via a logon script each morning.

As part of the SP3 update, there were issues updating the modified forms/reports.  We had to do this on each machine, even though the instructions on CustomerSource specifiy that this step only had to be done once.

How are others out there managing custom .DIC files across 20 client machines?

 

*This post is locked for comments

I have the same question (0)
  • K Day Profile Picture
    K Day 7,365 on at

    I currently work at a company where when we launch GP the it guys have created a DynamicsLauncher.exe which looks out to a shared location to see if there are any changes to either Reports.dic or Forms.dic and copies them down if the versions are different.  THen it launches dynamics with the set file after the updates are done.  This happens every time a user launches GP.  I have seen many configurations but this is the first time I have seen this and I think it is pretty neat.  There are 100 plus users here.  This way there is less opportunity to corrupt the reports when one user might be modifying a report and another user trys to print that one.  Always a local copy and always the most up to date.

    I also have seen clients all pointed to a centralized Reports and Forms dictionary on a file share.  You can use a UNC path in the dynamics.set file to pont to the shared dictionary.

    As long as you are making regular backups of these files, you should be okay.  I have seen discussion about SP3 corrupting these dictionaries.  One solution is that you can also export all your customized forms and reports to a *.package file. (this is an .xml file)  This is done through Tools - Customize - Customization Maintenence.  These can be imported back into a forms or reports dictionary if the whole .dic file gets corrupted at some point.  For instance, you could export your modified reports and forms, delete the reports dictionary file, open report writer (this will create a brand new Reports.dic wherever the dynamics.set is pointing), and then import the modified reports back into it.

    Hope that helps a little. 

  • Dan Lewis Profile Picture
    Dan Lewis 45 on at

    [quote user="K Day"]

    I currently work at a company where when we launch GP the it guys have created a DynamicsLauncher.exe which looks out to a shared location to see if there are any changes to either Reports.dic or Forms.dic and copies them down if the versions are different.  THen it launches dynamics with the set file after the updates are done.  This happens every time a user launches GP.  I have seen many configurations but this is the first time I have seen this and I think it is pretty neat.  There are 100 plus users here.  This way there is less opportunity to corrupt the reports when one user might be modifying a report and another user trys to print that one.  Always a local copy and always the most up to date.

    I also have seen clients all pointed to a centralized Reports and Forms dictionary on a file share.  You can use a UNC path in the dynamics.set file to pont to the shared dictionary.

    As long as you are making regular backups of these files, you should be okay.  I have seen discussion about SP3 corrupting these dictionaries.  One solution is that you can also export all your customized forms and reports to a *.package file. (this is an .xml file)  This is done through Tools - Customize - Customization Maintenence.  These can be imported back into a forms or reports dictionary if the whole .dic file gets corrupted at some point.  For instance, you could export your modified reports and forms, delete the reports dictionary file, open report writer (this will create a brand new Reports.dic wherever the dynamics.set is pointing), and then import the modified reports back into it.

    Hope that helps a little. 

    [/quote] 

    Thanks for the ideas.

    Centrally locating the DIC files by setting the UNC paths in the SET file sounds like a great fit for how we operate.

     Also - thanks for the .package info.

     Solution 1 is similar to what we do currently - except it is on logon to Windows, not Dynamics.

  • winthropdc Profile Picture
    winthropdc on at

    Have a look at my take on the subject.  What is now described as the Musgravion method. :-) 

    http://blogs.msdn.com/developingfordynamicsgp/archive/2008/08/20/automating-distribution-of-customisations-part-1.aspx

    http://blogs.msdn.com/developingfordynamicsgp/archive/2008/08/26/automating-distribution-of-customisations-part-2.aspx

    David Musgrave [MSFT]
    Escalation Engineer - Microsoft Dynamics GP
    Microsoft Dynamics Support - Asia Pacific

    Microsoft Dynamics (formerly Microsoft Business Solutions)
    http://www.microsoft.com/Dynamics

    mailto:David.Musgrave@online.microsoft.com
    http://blogs.msdn.com/DevelopingForDynamicsGP

    Any views contained within are my personal views and not necessarily Microsoft policy.
    This posting is provided "AS IS" with no warranties, and confers no rights. 

  • Dan Lewis Profile Picture
    Dan Lewis 45 on at

     @David:

     

    We are doing your Version 5 right now - except you have a bit more built in.  Ours is a simply robocopy script run at logon.  We also centrally manage the .bat file - the Startup item is simply a pointer to the BAT on the share also.

     We just ran into issues though after installing GP10 SP3 and had to touch each workstation to update the forms and reports.

     How could this have been avoided?

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Neeraj Kumar – Community Spotlight

We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…

Congratulations to the November Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > 🔒一 Microsoft Dynamics GP (Archived)

#1
Community Member Profile Picture

Community Member 2

#2
mtabor Profile Picture

mtabor 1

#2
Victoria Yudin Profile Picture

Victoria Yudin 1

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans