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

  • Dan Lewis Profile Picture
    Dan Lewis 45 on at
    Re: Re: Re: Re: Centrally Managing custom Dictionaries

     @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?

  • winthropdc Profile Picture
    winthropdc on at
    Re: Re: Re: Centrally Managing custom Dictionaries

    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
    Re: Re: Centrally Managing custom Dictionaries

    [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.

  • K Day Profile Picture
    K Day 7,365 on at
    Re: Centrally Managing custom Dictionaries

    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. 

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

Daivat Vartak – Community Spotlight

We are honored to recognize Daivat Vartak as our March 2025 Community…

Announcing Our 2025 Season 1 Super Users!

A new season of Super Users has arrived, and we are so grateful for the daily…

Kudos to the February Top 10 Community Stars!

Thanks for all your good work in the Community!

Leaderboard

#1
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 292,516 Super User 2025 Season 1

#2
Martin Dráb Profile Picture

Martin Dráb 231,436 Most Valuable Professional

#3
nmaenpaa Profile Picture

nmaenpaa 101,156

Leaderboard

Featured topics

Product updates

Dynamics 365 release plans