Logo
PREGNANCY
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
 
 
Windows Server

Maintaining Dynamics GP : Improving stability by Managing Dictionaries

5/23/2013 5:43:41 PM

Microsoft Dynamics GP uses dictionary files to hold application code, forms, and reports. Form and report modifications in Dynamics GP don't modify the underlying item; instead, modified forms and reports are modified copies of the original that are stored in the reports and forms dictionaries.

The key question facing companies is the placement of the dictionaries because this can impact the availability of custom forms and reports. Improper placement may mean that users don't get necessary customizations, so dictionary locations need to be set up properly with each client install of Dynamics GP.

We will look at how to set up dictionary locations in this recipe.

How to do it...

To change the location of a user's forms and reports dictionary:

  1. 1. Select Administration from the Navigation Pane. Select Edit Launch File under the Setup section on the Administration Area Page.

  2. 2. Enter the system password if prompted.

  3. 3. Click on the product having ID 0 and name Microsoft Dynamics GP. This is the main Dynamics GP application. At the bottom of the window are three dictionary locations for the Application, Forms, and Reports:

  1. 4. Changing the location of the application dictionary is not recommended as this is where the core business logic is stored and moving this file can negatively impact performance.

  2. 5. Select the Forms field and scroll to the right to see the full location. This is the location for custom forms. Changing this to a new location will create an empty custom forms file in the new location. If an existing custom forms field is in a different location, either enter the new location or use the file lookup to identify the new location. The same process applies to change the location of the Reports dictionary.

  3. 6. Each installed product outside of the core Microsoft Dynamics GP dictionary has its own application, forms, and reports dictionaries.

  4. 7. Select the Fixed Assets product and notice that the dictionaries have names specific to the Fixed Asset module ID.

  5. 8. Click on OK to save any changes.

How it works...

Dictionary control is an important piece of maintaining Dynamics GP. As new users are added and more instances are installed, it's important to ensure that the dictionaries are pointed to the right place. Without this, companies end up with an incoherent mess of customized windows and reports.

The two most common placements are locally on each user's machine or centrally on a file share. Local placement was preferred for a long time as this resulted in significantly fewer incidents of dictionary corruption. Typically, a master copy of the forms and reports dictionaries was maintained and copied to user machines via a network login script.

Over time the problem of corrupt dictionaries was significantly reduced. Improvements in Dynamics GP and network reliability made dictionary corruption extremely rare. This made centrally managing dictionaries much more feasible.

There are pros and cons to each approach. Locally managing dictionaries provides a type of backup. In the event of damage to the dictionary file, the file can be replaced by another user's copy. Conversely, locally managing dictionaries lets users have different customizations from their peers as each user's files can be unique. Finally, locally managing dictionaries permits forms and reports to be customized while Dynamics GP is in use.

Local placement of dictionaries does cause additional IT overhead as it involves creation and management of login scripts to update dictionaries with changes. Also, if users leave Dynamics GP logged in over several days dictionary updates won't propagate to their machines during that time period. Finally, users could customize forms and reports locally only to have them overwritten the next day when central dictionaries are rolled down via a login script.

Central management of dictionaries provides a consistent experience for users as everyone gets the same set of customizations in their dictionaries. Backup can be centrally managed as well. Customizations can't be made directly while other users are in the system. However, forms and reports customizations can be exported locally, modified, and then applied to a central dictionary.

There's more...

For administrators there is another option for setting dictionary locations outside of the interface.

Dynamics.set file
Installed dictionaries and their locations are held in the Dynamics.set file. The recipe explained previously shows how to set dictionary locations via the interface. This process changes the Dynamics.set file. The same changes could be made in the file with Notepad instead of via the interface. The Dynamics.set file could also be copied to a user's computer (assuming that they have the same modules and dictionary locations). This process is faster and easier than changing each user's Dynamics.set file via the interface.
Other -----------------
- Client Access to Exchange Server 2007 : Using Cached Exchange Mode for Offline Functionality
- Client Access to Exchange Server 2007 : Using Outlook 2007 Collaboratively (part 3) - Using Group Schedules
- Client Access to Exchange Server 2007 : Using Outlook 2007 Collaboratively (part 2) - Sharing Information with Users Outside the Company
- Client Access to Exchange Server 2007 : Using Outlook 2007 Collaboratively (part 1)
- Windows Server 2003 on HP ProLiant Servers : The Physical Design and Developing the Pilot - Time Services (part 2) - Domain Time Hierarchy
- Windows Server 2003 on HP ProLiant Servers : The Physical Design and Developing the Pilot - Time Services (part 1) - Time Services Role in Authentication
- Windows Server 2003 on HP ProLiant Servers : The Physical Design and Developing the Pilot - Network Services
- Workflow in Dynamics AX 2009 : Workflow Life Cycle (part 3) - Activating the Workflow
- Workflow in Dynamics AX 2009 : Workflow Life Cycle (part 2) - Creating the Workflow Document Class
- Workflow in Dynamics AX 2009 : Workflow Life Cycle (part 1) - State Model
- Workflow in Dynamics AX 2009 : Workflow Architecture
- SharePoint 2010 : Configuring Search Settings and the User Interface - Search Tabs and Pages
- SharePoint 2010 : Configuring Search Settings and the User Interface - Search Scopes
- SQL Server 2008 R2 : Performance Monitoring Tools (part 12) - Viewing Data Collector Set Results in Performance Monitor
- SQL Server 2008 R2 : Performance Monitoring Tools (part 11) - Creating Data Collector Sets in Performance Monitor
- SQL Server 2008 R2 : Performance Monitoring Tools (part 10) - Creating an Extended Events Session
- SQL Server 2008 R2 : Performance Monitoring Tools (part 9) - Creating an Extended Events Session
- SQL Server 2008 R2 : Performance Monitoring Tools (part 8) - Extended Events Catalog Views and DMVs
- SQL Server 2008 R2 : Performance Monitoring Tools (part 7) - SQL Server Extended Events
- SQL Server 2008 R2 : Performance Monitoring Tools (part 6) - SQL Server Utility
 
 
Most view of day
- Microsoft Exchange Server 2010 : Completing Transport Server Setup (part 3) - Enabling Anti-Spam Features
- Accessing and Using Your Network : Learning Some Common Network Tasks
- Deploying Applications (part 1) - Preparing the Lab, Planning Deployment, Choosing a Deployment Strategy
- Microsoft Exchange Server 2007 : Consolidating a Windows 2000 Domain to a Windows Server 2003 Domain Using ADMT (part 4) - Migrating User Accounts
- Troubleshooting Hardware, Driver, and Disk Issues : How to Use Built-In Diagnostics (part 4)
- Using Microsoft SharePoint with Microsoft Dynamics CRM Functions (part 2) - Displaying Data Using BDC in Microsoft Office SharePoint Server
- Windows Server 2012 Administration : Managing Printers with the Print Management Console (part 3) - Using the Print Management Console
- Windows Server 2008 R2 high-availability and recovery features : Installing and Administering Failover Clustering (part 7) - Create shared folder on cluster, Testing Failover of Cluster
- Microsoft Project 2010 : Defining Project Resources - Using the Task Form View to Add Additional Resources
- Sharepoint 2013 : Managing Site Security - Create a SharePoint Group for a Site
Top 10
- Migrating to Exchange Server 2007 : Migrating from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 (part 7)
- Migrating to Exchange Server 2007 : Migrating from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 (part 6)
- Migrating to Exchange Server 2007 : Migrating from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 (part 5) - Moving Mailboxes
- Migrating to Exchange Server 2007 : Migrating from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 (part 4) - Installing Exchange Server 2007 on a Server System
- Migrating to Exchange Server 2007 : Migrating from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 (part 3) - Installing Exchange Server 2007 Prerequisites
- Migrating to Exchange Server 2007 : Migrating from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 (part 2)
- Migrating to Exchange Server 2007 : Migrating from Exchange 2000 Server or Exchange Server 2003 to Exchange Server 2007 (part 1) - Planning Your Migration
- Migrating to Exchange Server 2007 : Deploying a Prototype Lab for the Exchange Server 2007 Migration Process
- Migrating to Exchange Server 2007 : Moving to Native Mode in Exchange
- Migrating to Exchange Server 2007 : Understanding What’s New and What’s Different with Exchange Server 2007
 
 
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro