GP Utilities "breaks" connection to server

(0) Share

Report

Posted on by Lyn Barr

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.

/* Date: 06/24/2013 Time: 19:05:44

SQLSTATE:(08001) Native Err:(10060) stmt(0):*/

[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*/

/* Date: 06/24/2013 Time: 19:05:44

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!

Thanks,

Lyn

*This post is locked for comments

I have the same question (0)

All responses (17)

Answers (1)

KirkLivermont 5,985 on at

Like (0)

Report

Hi Lyn,

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.

Kirk

Was this reply helpful? Yes No
Lyn Barr 1 on at

Like (0)

Report

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.

Was this reply helpful? Yes No
KirkLivermont 5,985 on at

Like (0)

Report

Lyn,

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?

Kirk

Was this reply helpful? Yes No
Richard Wheeler 75,848 Moderator on at

Like (0)

Report

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.

Was this reply helpful? Yes No
Lyn Barr 1 on at

Like (0)

Report

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.

Was this reply helpful? Yes No
Lyn Barr 1 on at

Like (0)

Report

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.

Was this reply helpful? Yes No
Suggested answer

Richard Whaley 25,195 on at

Like (0)

Report

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.

Was this reply helpful? Yes No
Lyn Barr 1 on at

Like (0)

Report

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!

Was this reply helpful? Yes No
Lyn Barr 1 on at

Like (0)

Report

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.

Was this reply helpful? Yes No
Richard Wheeler 75,848 Moderator on at

Like (0)

Report

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?

Was this reply helpful? Yes No