[Mary Mallazzo]

Hello
What is the best practice to modify reports in GP, without having to do it off hours?

Thank you

——————————
Mary Mallazzo
Fromkin Brothers
Edison NJ
——————————

[Matthew Arp]

Depends on the environment, are you making the changes in a Terminal Server environment(shared) or is GP deployed to each user’s desktop? We use Terminal Servers and I will generally customize the report on my local instance of GP and then either export the report and import on the terminal servers or just copy the modified report dictionary that contains the modified report.

——————————
Matthew Arp
Business Systems Developer
Hunton Group
Houston TX
——————————
——————————————-

[Mary Mallazzo]

We are currently running with GP deployed on each users desktop with a shared dictionary.  

Thanks

——————————
Mary Mallazzo
Fromkin Brothers
Edison NJ
——————————
——————————————-

[Matthew Arp]

I’d recommend running your local workstation without the shared dictionary, then you can copy your local updated dictionary to the network share for users to get. Are you encountering any specific issues?

——————————
Matthew Arp
Business Systems Developer
Hunton Group
Houston TX
——————————
——————————————-

[Mary Mallazzo]

How do I do that?
How do I change GP to point to a dictionary on my local machine?
If I then want to copy the updated dictionary to the server, does it need to be done when no one is using GP?
Or would it be better to export/import the changed report?

Thanks

——————————
Mary Mallazzo
Fromkin Brothers
Edison NJ
——————————
——————————————-

[Matthew Arp]

If you examine your DYNAMICS.SET file, you should see that your FORMS & REPORTS dictionaries are pointed to your shared network location. (Its best practice to have the unmodified PRODUCT dictionary files stored locally). So you’d simply edit your DYNAMICS.set to point to your local GP installation folder and then be sure to copy those files into your GP installation folder. You could then make the modifications on your local machine, test, etc. Then when you’re ready copy the relevant modified dictionary file to the shared network location. The official answer would be to use the import/export feature in GP, but honestly I usually just copy the dictionary file.

——————————
Matthew Arp
Business Systems Developer
Hunton Group
Houston TX
——————————
——————————————-

[David Musgrave]

I agree with .

I actually recommend against using network shared custom dictionaries as it causes performance issues and is prone to dictionary corruption.  Please see my articles from 2008 explain the issues and providing alternate solutions. These have been described as the Musgravion Principles. ??

https://winthropdc.wordpress.com/2008/08/20/automating-distribution-of-customizations-part-1/

https://winthropdc.wordpress.com/2008/08/26/automating-distribution-of-customizations-part-2/

I recommend always working on a local copy of custom reports and forms until you have it working as desired. Then it can be deployed once completed using Customization Maintenance (while users are still logged in). Or you can copy the file manually, or automatically from an update area as per my articles.

Regards

David

——————————
David Musgrave MVP, GPUG All-Star

Managing Director
Winthrop Development Consultants

Perth, Western Australia

http://www.winthropdc.com
——————————
——————————————-

[David Musgrave]

PS: I believe that if you are editing a report in shared reports.dic and another user prints the same report that is when the reports dictionary can be corrupted.

——————————
David Musgrave MVP, GPUG All-Star

Managing Director
Winthrop Development Consultants

Perth, Western Australia

http://www.winthropdc.com
——————————
——————————————-

[Scott Davis]

Along with the methods outlined by Matt and David, I’ve previously used a method where all your modified forms and reports are deployed via .bat file. It takes a bit more time to set up and involves some training of users, but keeps everything exactly the same and makes change deployment easy.

Once you’re happy with a unified set of Forms and Reports in your .dic and .vba files, you create a .bat file that copies all the explicit .dic and .vba files out of your local GP installation and places them in a shared drive on your network (ie. \ServerNameGPSharedGPReports). Access to this file should only be given to users who are allowed to make changes to the organizations reports and who have been trained on how to use it.

Then you create a second .bat file that does 2 primary things:
1. Copy all the .dic and .vba files from your shared location to the local installation.
2. Launch GP.

Then you deploy a shortcut to the second .bat file to all user workstations and instruct users to always use that shortcut. This guarantees that every time they open GP they will have the latest version of modified forms and reports, and if you want to make changes, you make them on your local machine and push them up to the server, then the next time each user opens GP with their local .bat file they get the latest version. You can also modify the shortcut to use the GP icon if it helps users remember what it’s there for.

This method is my personal favourite, but I’m also biased as it’s the first one I learned and have customized it to add automatic backups of .dic and .vba files with a time and date stamp in case things go haywire and you can always revert back.

——————————
Scott Davis
Trudell Medical Limited
London ON
——————————
——————————————-

[David Musgrave]

Hi

If you look at my articles, it uses both a batch file and xcopy to only copy new and changed files and also runs the batch file during the login script.

The batch file can be used manually on Terminal servers when no one is logged in. All workstations can either run the batch file or just logout and login.

Regards

David?

——————————
David Musgrave MVP, GPUG All-Star

Managing Director
Winthrop Development Consultants

Perth, Western Australia

http://www.winthropdc.com
——————————
——————————————-