putting vba code into production 1

[SpeedBWild]

On my PC the Dynamics.set points to the forms.dic and report.dic that are both on my hard drive. This has allowed me to modify and test some vba code behind a form without affecting other users. All of the other user have their Dynamics.set on their hard drive pointing to the forms.dic and report.dic that sit on one of our servers. How do I bring my code changes over to production. What do I need to modify on the server so that everyone see my changes. Do I need to create a shortcut to open Great Plains Dynamics on the server and then modify the code according?

Thanks,

 

[winthropdc]

There are two answers to this question.

1) Use Tools >> Customise >> Customisation Maintenance to export your customisations as packages and import them on a workstation which is pointing to the shared dictionaries. If there is VBA code, this will have to be repeated on all workstations as VBA code is stored in the same folder as the runtime engine and cannot be pointed to a shared location.

2) This is my preferred option. DON'T USE shared forms.dic and reports.dic files. It makes it harder to modify code as you cannot always get exclusive access and shared custom dictionaries can get corrupted much easier.

Instead, use a central update area which contains the latest dictionaries, Launch file, runtime and VBA files (but not the DEX.INI file). Make sure that all systems use the same folder structure and that any DLLs referenced in your VBA code is stored using the same pathname.

NOTE: The Dex.ini file contains some settings which are unique to individual workstation and should not be included in the update area.

Then using some scripts which execute during login (basically a fancy xcopy clause) all workstations can be updated to match the template in the central update area.

So after you make your change locally, just "publish" it to the update area and next login everyone will have your updates.

Let me know if you want more info.

David Musgrave [MSFT]
Senior Development Consultant
MBS Services - Asia Pacific

Microsoft Business Solutions

http://www.microsoft.com/BusinessSolutions

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

 

[SpeedBWild]

Sorry, it taken me so long to get back to this item. I do have a few more questions as I'm not sure I fully understand what you are telling me. The forms.dic and reports.dic sit on a server. Each client has it's own dex.ini file and their own dynamics.set. The dynamics.set file points to the forms.dic and reports.dic on the server.

I that makes sense because then everyone uses all the same report and forms and if one person create a new one everyone has access to it.

I did what you said above for solution 1 on a local machine and it worked. I am not sure I complete understand solution 2 yet, so I did not try to do that. But what happens when GP needs to be installed on a new client? I have to keep my pacakge some place and re-run it? Yuck!

Also, I am getting ready to upgrade and I'm not sure which I should do first the VBA code modification or the upgrade. Any suggestions?

Thanks a bunch,

 

[bradth]

When you have a package compiled through the customization maintenance screen, you need to keep that package in order for the new client to receive all the data for the VBA customizations that you have made. Its kind of a pain, but basically its like an update you make after you install GP. Also, in order for others to see the customizations after you install the package, you need to set them up with the customized forms, which can be done through the Advanced Security form (choose whether their using the original or modified form). Good luck.

 

[stef315]

If you are using a shared Forms and Reports dictionary, you only need to copy the Dynamics.vba file from a working workstation to the new one. You don't need to re-import the package file.

 

[bradth]

That works too, I've had to do that for some imports b/c the customization maintenance wasn't quite importing all the forms due to an export error on one of the packages.