Tag Archive: gp


The official System Requirements for Microsoft Dynamics GP 2018 document from Microsoft does not give Network requirements. So some companies may forget to ask or be tempted to think it doesn’t matter.

In fact, you must be aware that:

Dynamics GP is supported only when client and SQL databases are on the same Local Area Network (LAN).

Wide Area Networks (WAN), Virtual Private Networks (VPN), or any other variant is not supported and will cause at minimum poor performance, and at worst corrupted data.

A minimum of 1GBps LAN is required for normal GP performance.  This also means that notebook users should be discouraged from using Wi-Fi to run Dynamics GP.  CAT5 cabling is the minimum acceptable connection.

If you have a mix of speeds with LAN and WAN/VPN users, it gets even scarier.  Dynamics GP tags each transaction with a Dex Row ID and that next number is reserved until the transaction is complete.  If you have a local (fast connection) client and a remote (slow connection) client processing orders simultaneously, there is a possibility that these IDs could be assigned to the wrong transaction depending on whose transaction completes faster, which would corrupt the transaction.  That is a very simplified layman’s description but should serve to show the importance.

As faster internet speeds become more cost-effective it gets more tempting to put space between client and servers or put the SQL server in a data center, but even if your network card says 1Gbps, it is not going to achieve that speed over a lossy WAN or VPN with a likely maximum of 50-200Mbps.

  • If you are implementing Microsoft Dynamics GP for the first time, make sure you review the system AND network requirements carefully.
  • If you are already running Microsoft Dynamics GP and you are thinking of making a change to your network make sure you contact your Dynamics GP Partner to review your plans BEFORE making any changes.

Additional resources:

short article on the problem of running database applications over WAN. Terminal Services is one solution when users and the database(s) reside in different locations.  The Dynamics GP Web Client is another solution, but still requires a second collocated server for the underlying GP Client, IIS, and connection management database.

This article by Dave Musgrave is the best explanation on the subject of WAN ODBC communications.

“You do not have permission to open this file.”  This error is always, always, always in reference to insufficient permissions on a shared folder or file, usually a forms or reports dictionary.  This behavior could happen when users are forcibly disconnected from a network resource, or unsynchronized AD Catalog Server permissions are accessed causing a conflict in access rights.  We usually see it when a new GP user has not been granted sufficient rights (Read/Write/Modify) in the shared file area (usually GPShare).  This issue may also present itself as an “Unknown Dictionary Error” if it appears prior to SQL login.
The GP launch chain of events is as follows:
  1. GP opens with Dynamics.exe calling business logic dictionaries listed in the Dynamics.set file.  Some of these paths may be on a different server.  No SQL connection is attempted, requested, or required at this point.
    1. If all dictionaries are accessible and open for read/write operations,  the application launch proceeds to validate the SQL user.  If dictionaries do not have proper permissions or are inaccessible, the login fails with the “You do not have permission to open this file” error.  Note that depending on domain file sharing policies, if a terminal server still shows the user running a copy of Dynamics.exe, a domain group policy may deny the user access to a second copy of the file, which would yield the same error since access would be specifically denied.
  2. Once Dynamics.exe loads all the logic specified by the SET file, the SQL login screen opens for the user.
  3. Data is provided by the SQL Server databases, and windows are loaded from the logic dictionaries mentioned in #1 above.
  4. To finish the operations scenario, GP transactions are client/server, with GP requesting as much data as necessary to satisfy the query which is then processed on either client or server depending on the transaction.  This is done through many ‘top 25’ queries until the desired data has been received to guard against large blocks of data transmitting at one time possibly overloading the network.  This constant request for data and the validations against it are the reason that server and client must reside on the same LAN.

GP & SQL Compatibility

I replied to a GPUG question earlier today from someone wanting to use SQL 2016 with GP 2015.  It bears repeating here and applies to similar situations as well.

When Microsoft says not compatible, they mean it. It may work, but it’s not supported. If you do run into an issue with compatibility down the road, you have just burned all bridges, since you won’t likely be able to restore it later to a supported SQL version. At that point you can only hope that you’ve kept a copy of databases from the earlier SQL version and reenter everything from that point, or start over. It’s usually a deprecated function is specified in GP coding that will be the problem, and the only fix is to rewrite the software.

For years I was the “Damn the torpedoes, full speed ahead” guy, the one that could always trick the system into making it work after a client broke it, but after seeing the destruction and mayhem it can cause down the road (read potentially hundreds of consulting hours), it’s wise to trust Microsoft’s compatibility list. It’s there for a reason.

This relates immediately to a server install I was performing, but is something to keep in mind.
1. Don’t try to use SSRS (SQL Server Reporting Services) Reports in GP if SQL is an Express version of 2005, 2008, or 2012. According to GP 2010 System Requirements, SQL Express is supported for everything but Analysis Cubes. I spent too much time trying to get it to work until I came across a Blog post flatly stating that it does not work. Even running GP as a local administrator and logged in with the SQL sa account, I continued to get the error that I did not have permission to install to that location. I did set security in the Reports Site Settings (you need to run IE as administrator the first time to add yourself), gave our user, domain admins, and domain users full access to everything, then repeated the permission settings for folder security. I even went so far as to set security permissions on the file folder structure in Windows Explorer – same error. As I stated, the Blog post was sufficient to put a halt to my efforts.
2. The client wanted to use SQL 2012, which for GP2010SP3 supports. However, Management Reporter would not validate on SQL 2012 to allow creation of the databases. In this case, Management Reporter System Requirements DO state SQL 2005 or 2008 are supported, with no mention of 2012.

One additional note – You will have little or no trouble installing Management Reporter Server components if you download and pre-install the Access 2010 Runtime and Access Runtime SP1 from Microsoft Downloads. If you don’t run those first, setup will hang on the MR Server configuration windows. If it’s a 64-bit OS, install 64-bit Access Runtime and SP. If Office 32-bit is installed on the server, you cannot just run the 32-bit Access Runtime install, because it senses a mismatch between the Windows Server and Office platforms. The only option is to uninstall MSOffice 32-bit and then install the 64-bit Access Runtime. You will then need to install Office (Word, Excel) as 64-bit.