Archive for March, 2018

Dynamics GP Process Server, available since the early versions of Great Plains Dynamics, has been pretty much ignored by most of us throughout the years.  Yet it can do so much to assist in many situations.

Since most GP users (and honestly, many GP consultants) have never heard of Dynamics Process Server, let’s begin by explaining its purpose.  As explained in a previous post, Dynamics GP is a Client-Server application, meaning that processing is done on both the client and in SQL Server database processing.  We insist on fast servers and great server performance, yet overlook the performance of the equally-important workstation component.  Many of the posting and printing functions are done at the workstation, and if the workstation is underpowered, has too many other applications open in the background, or even if the user needs to push on to the next task quickly but is blocked by other GP tasks already running on the client, many times these workstation-intense tasks can be sent to a Dynamics Process Server (which we will refer to as DPS going forward).

A DPS ‘server’ is nothing more than a GP client installed on a workstation or server either on a dedicated or an as-needed basis, possibly a part-time employee’s workstation, or a user who is out for the day.  Specific tasks are assigned to these servers through the setup window in GP.  The good news?  There’s nothing to install since the files are already on every GP client workstation by default.

Where DPS can really make a difference is in boosting both actual and perceived performance.  Faster clients can be used to process long-running, processor or RAM-intense tasks not only making the user’s workstation available for additional tasks immediately but distributing the workload.  As an example of this, consider a GP user who needs to run Accounts Receivable Aging, process statements, and enter Sales Orders.  Without DPS, the user would run the aging, wait until completed, process statements, wait until completed, then enter sales orders.  Even if these tasks could be run concurrently on the same workstation, RAM, CPU, and disk activity would slow further activity to a crawl, or possibly even crash the application.  With DPS in place, the user sets up the processes as usual, but rather than clicking the process button, they have the option to offload the processing to DPS.  At that point, they can proceed to the next task with no processing overhead on the workstation.

I will expand on this topic in upcoming posts.


I have a perfect answer for the children protesting gun rights. After checking several sources, it seems there is an average of 11 teenagers killed each day by other teenagers texting or talking and driving. Taking these children’s logic to a relatively logical step forward, we just take away all cell phones and their cars! Phones and cars are killers and these children should not be allowed to apply for the use of one until they’re at a responsible age.  There are far more deaths by phone than guns any day of the year.

Let’s take this one more logical step.  Eleven deaths a day doesn’t include the number of suicides every year caused by shaming and bullying, much of it texted or messaged on these over-entitled children’s phones. Given that, it makes sense to take phones away until they’re old enough to respect the power in their hands.

Kids might actually have to interact with those around them face-to-face.  Without phones, they’d have time for homework, sports, and time with their families.  Compare that to what I see every day – kids from grade school through high school walking to and from the bus with shoulders slumped, staring down at their phones as they text ignoring the world and even those around them, not to mention the vehicles swerving to avoid them as they cluelessly wander down the middle of the street in a chatroom fog.

Helicopter parents worried about where their children are don’t need to give them phones.  A simple GPS tracker will suffice to locate them at school and around the neighborhood if you feel the need, or even better – old-fashioned parenting and trust when deserved.  Yes, you read correctly.  When. Deserved.  Not because they whine, cry and throw tantrums – when. deserved. period.

Let’s get these instruments of destruction out of our children’s hands!

Just sayin…

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.