Shared reports dictionaries

[barbola]

I used to have where each client had its own reports dictionaries, and users would import a report package to include newly modified reports.

After upgrading to GP 9.0 I pointed all the clients to a main reports dictionary on the network. Don't worry, it is well backed up!

I was wondering if this makes it alot slower for reports to print? I've had some complaints and our AP person gets stuck/frozen every time she runs a check batch and has to kill GP and recover the batch.

thanks

 

[winthropdc]

Here is something I wrote on the subject. I recommend AGAINST shared dictionaries.

Shared Application vs Synchronised Application
==============================================

Can I use a Shared Application folder for Great Plains?

It is possible to have a central shared application folder however, this is normally only used in a Terminal Server environment. To use this configuration in a LAN environment could cause performance and network congestion issues due to the additional network traffic required.

You will need to do an initial CD installation on each workstation as this will add the system and registry components of the install as well as the client itself.

Once you have a client installed, you can copy the application dictionaries and DYNAMICS.SET file between workstations (as long as the install folder is the same).

The Runtime files *.exe, *.dll, *.tlb and Dex.dic can be copied between workstations.

Custom report and forms dictionaries can be shared, but I prefer to keep them local as well and copy them between workstations.

VBA code must be local to each application install and the *.VBA files can be copied only if all external references are the same for all machines. So if you use any DLLs place them in the same path (usually the application folder) for all workstations. Otherwise you will need to export and import packages.

My preferred configuration is to have everything local to each workstation and then use a login script to synchronise from a central Update area.

This has the following benefits.

1) Never being locked out of report writer or modifier because others users are in the system.

2) Reduces chances of corruption the custom dictionaries.

3) Improves performance as base resources and customised resources are read from local drive rather than network.

4) Decreases network traffic as base resources and customised resources are read from local drive rather than network.

5) Allows customisations to be fully tested before being deployed.

6) VBA has to be stored locally in .VBA files anyway.

If you want more info, let me know and I can send you the details of how to do this.


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.

 

[jymm]

I have been using a shared dictionary for 7 years or better and have had no problems with speed or lockups that were not attributed to the temp files that GP was leaving on the workstation... but then I really only have 15 users going against GP at any one time and the chances of more than one actually printing at the same time are slim.

 

[barbola]

thanks for the info. We have about 15 users sharing that dictionary. There are about another 10 users on a terminal server that has two reports dictionaries, and the users have separate launch files depending on what they use.

I'll just have to keep an eye on it.

b

 

[jazgeek]

here's a happy medium for you.


set up a login script for each user that copies the "master" report dictionary to the local station.

centralized admin and the user can be a maximum of 24 hours out of synch until the user logs in to the workstation again and get's the new copy down.

-----------
and they wonder why they call it Great Pains!

jaz

 

[barbola]

set up a login script for each user "

ya like I know how to do that! I will have to ask the network guys.

well, not sure if this is related but our payables batches are taking hours and hours to run. The user is leaving them overnight.

 

[CAAB73]

set up a login script for each user"

Would you have an example of the script? Thx!

 

[jazgeek]

copy X:\sharedreports\reports.dic c:\program files\microsoft\etc etc etc\reports.dic

put that in a batch file, put it in the login directory, set the users profile to launch it on login and bob's your uncle.

-----------
and they wonder why they call it Great Pains!

jaz

 

[winthropdc]

If your users are logging onto an NT Domain, then the answer is right there ....... use the NT login scripts.

The best performance is obtained by storing all dictionaries locally on the client. This also minimises network traffic.

The Report writer can be used on a client without corrupting the master version, and only sent to the central update area when tested.

Below is example logon script used to move only newer files from a central update area to the clients, it also can be used to map drives:-


rem Disconnect Existing Shares
net >nul: use u: /D

rem Updating Dynamics System
net use u: \\sqlserver\update
if exist c:\dynamics\dynamics.exe xcopy u:\*.* c:\*.* /E /C /R /Q /D /Y
net use u: /D


The only issue now is to ensure that the DYNAMICS.SET, DEX.INI or any modified form and report dictionaries have a date/time stamp later than the client machines.

We use a TOUCH.EXE command to set the time to 23:59 on these files, it normally guarantees that at the next logon, the client will be updated.

We have used this technique to roll out updated custom dictionary, new modules, change DEX.INI settings, and even update Dexterity runtimes.

I hope this helps. I can email the TOUCH.EXE program to you, if necessary.

Also, you can download it from ftp://ftp.winthropdc.com/outgoing/touch.zip

David Musgrave [MSFT]
Senior Development Consultant
Escalation Engineer - Great Plains
Microsoft Dynamics Support - Asia Pacific

Micorosoft Dynamics (formerly Microsoft Business Solutions)

http://www.microsoft.com/Dynamics

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.