I have a crazy one for you. I upgraded a client from GP 10.0 to GP2013. The upgrade was smooth sailing, all work on the server was great. Upgraded forms & reports, no problem. No failed tables or other errors of any kind. Ran GP Utilities on the server, with no issues.
Installed GP2013 on the first workstation. The install was smooth sailing, no errors or issues of any kind. Prior to launching GP Utilities, my NIC Card shows I am connected to the domain, and I can ping the server, browse the internet, and see all my other workstations under the "Network" heading in Windows Explorer. My ODBC tests successfully.
When I launch GP Utilities, it hangs and eventually (45 minutes later) returns an error message. DexSQL log shows a variety of connection errors such as:
/* Date: 06/24/2013 Time: 19:05:44
SQLSTATE:(08001) Native Err:(10060) stmt(0):*/
[Microsoft][SQL Server Native Client 10.0]TCP Provider: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
[Microsoft][SQL Server Native Client 10.0]A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to*/
SQLSTATE:(S1T00) Native Err:(0) stmt(0):*/
[Microsoft][SQL Server Native Client 10.0]Login timeout expired*/
After I end-task, my NIC card shows I am connected to an unmanaged network, and I can no longer browse the internet, ping the server, or test my ODBC successfully.
However, I CAN still ping the other workstations in my domain, both by name and by IP.
Getting the NIC (network) card reset back to the domain has been a hit-and-miss process for me. I toggle back & forth between static & dynamic IP addresses. I disable/enable. I shut down & restart. I use Windows Explorer to attempt to view contents on another workstation, which allows me to enter credentials. I then re-do all the other steps (ping, disable/enable, restart/shut down), and eventually, the network connection comes back.
One of the errors I keep seeing is that the DNS Server is not responding. However, nothing has changed on the server; this is all on the workstation.
I could go on, but I think I am rambling. Let's maybe start with this, and see if you have clarification questions, and tell me what you guys think!
Have you tried manually deleting and recreating the ODBC connection? I had a similar (though less extensive) problem today and this seems to have resolved it.
Yes, Kirk, I actually did that many times, sometimes using the server instance name, and sometimes using the IP address.
I verified that the firewall & antivirus are off on both the workstation & server, I disabled Named Pipes in the SQL Server Configuration Manager, and I looked for warnings/errors in the server's Windows Event Viewer (nothing relevant).
I currently have Microsoft reviewing the contents of a NetMon (Network Monitor) log that was captured both on the server & workstation during the time that the error occurs.
For now, I have not resolved the error, but I did work around it. In case anyone else ever has this problem, you can open the dex.ini in the Program Files\GP\Data folder, and set Synchronization=FALSE.
Then, just launch GP instead of launching GP Utilities. This allowed me to get into GP and get back to work.
Meanwhile, I can recreate the issue any time I like, by manually launching GP Utilities.
Sorry I wasn't able to help but thank you very much for the information. In case I ever need to use this work around do you know if there are any downsides to turning synchronization off?
If you were to create a new DSN for this instance, does it connect successfully? Is it jsut GP that fails to connect or do other applications have the same issue? Try different versions of the SQL client when creating the DSN.
Richard E. Wheeler 2013 and 2014 MVP
Member Microsoft Academic Alliance
www.rbsolutions.com Revered Business Solutions Ballston Lake, NY 518-877-0763 x10
The synchronization process verifies the versions of each product installed against those installed on the server. In the event that you install a different service pack version of GP on the client than was on the server, then you will have some problems using GP. The Utilities process is designed to prevent that.
I created a variety of DSNs, using all of the different version - SQL Native Client 10.0, SQL Server, and SQL Native Client. (Those were the only three installed on my workstation.)
Only the SQL Native Client 10.0 and SQL Server versions worked, but I believe the SQL Native Client didn't work because it is older and probably not compatible.
What version of the Native Client ODBC driver are you using on the workstation? The server install puts a new copy on the server but the work station install, if it sees a Native Client ODBC driver does not update it. Get the newest ODBC driver and change that first. You will need to delete the ODBC connection and re-create it after installing the new drivers.
Richard L. Whaley Author, Publisher, Consultant
Enhancing your Dynamics Knowledge!
It was the Native Client 10.0. I don't have the full, specific version number handy, but you're right, it should be Native Client 11.0 with GP2013. I will try this tomorrow, to see what happens. Thanks for the suggestion!
For clarification, I just realized that the ODBC driver is based on the SQL version, not the GP version. This client is running SQL Server 2008 R2, so the correct driver for them actually would be the SQL Server Native Client 10.0.
What I can do is download the latest driver, because perhaps there is an update that will help to resolve this. Also FYI, the one particular computer where I had this issue was brand-new, so I don't believe there were any pre-existing drivers prior to my GP install.
Over the years I have seen where older SQL clients work and the newer ones do not. You need to isolate whether it is a SQL or GP problem. When you are creating the DSN's are you able to create a successful connection? When you return to GP, it is then you have the connection issue? If you run the SQL Profiler when trying to connect does it tell you anything?
I can successfully connect with all of the ODBC connections I've created. In the dex.ini, I set SYNCHRONIZATION=FALSE, and was able to log into GP with no problems. It is specifically only when I run GP Utilities that I have a problem.
I did create a log by running a Network Monitor application, but will try a SQL Profile also.
Thanks for all your ideas, Richard!
"C:\Program Files (x86)\Microsoft Dynamics\GP2013\DynUtils.exe"
Make sure the properties of Dynamics Utilitles shortcut looks like this. Perhaps somehow the path is wrong and you are looking at the old GP Utilities.
Yet another great idea, thanks!
Definitely a new and interesting issue! I don't have an answer, but some ideas to try in case you have not yet:
- Have you ruled out malware/viruses on this computer?
- Have you tried logging into the computer as the local built-in administrator to see if the issue persists?
Also, is this happening on only one computer? All other computers can run Utilities with no issues? Or is this happening on multiple computers for this client?
Victoria Yudin - Dynamics GP MVP (2005-2015)
Want to use Excel, Crystal and SSRS with Dynamics GP? Check out GP Reports Viewer
It happened on the first (and only) two workstations where I attempted to run GP Utilities. One was a brand-new workstation, which never had GP installed, and the other was a previously existing workstation with an older version of GP installed.
I uninstalled the client firewall/antivirus application on the older workstation, turned off that application's service on the server, and still had the same problem.
I haven't logged in as a local admin, but I'm headed onsite now & will give it a try!
Thanks to you, and to Richard, for your helpful ideas!
FYI, after all of that, the issue was the antivirus/firewall application this client was using. I had asked their network/IT company to verify that all necessary exceptions & whatnot were configured, and they had assured me that they were, but once we actually uninstalled the antivirus from the server, we ran utilities successfully. After reinstalling the antivirus on the server, the GP Utilities once again hung & “broke” the network connection.
I’ve worked with their IT company to open all necessary ports & program exceptions in their firewall/antivirus, and the I’ve run GP Utilities multiple times, from every workstation.
I WOULD LIKE TO THANK EVERYONE FOR ALL THEIR EXCELLENT & HELPFUL SUGGESTIONS OVER THE COURSE OF TROUBLESHOOTING THIS ISSUE!
Richard Wheeler, Richard Whaley, Victoria Yudin, and Kirk Livermont - Thank you for your help!