GP2010 ODBC\DSN Not Connecting to Server

(0) Share

Report

Posted on by Jim Lines

Hello community!

Quick Summary of my problem: I can't get my ODBC DSN on Terminal Server to see my SQL Server 2008. Recently set up the new GP SQL Server2008 with no problem everything installed, setup and working well. No matter how I try to set up the System DSN, it won't see the SQL Server name in the drop down box and if I type it manually, it still fails. I've tried having the GP client set it up, used the regular DSN setup in Admin Tools and also use the ODBC32.exe to verify setups. Non of those will connect. I've seen something like this before and think it had something to do with remote access to SQL. I've tried just about everything on the client side and still can't get it to work. Any ideas?

Additional: I can ping the server. The SQL server itself have GP installed and there are no problems. I can view shared folders on that server.

The message I am getting from GP Utilities when I first login is "Your attempt to log into the server failed because and unknown error occured when the user ID and Password were being verified. Attempt to login again"

Any suggestions?

Thanks in advance.

Jim

*This post is locked for comments

I have the same question (0)

All responses (5)

Answers (0)

Jim Lines 4 on at

Like (0)

Report

Additionally, here's the message from the ODBC DSN Setup when I try to test the connection:

Microsoft SQL Server Native Client Version 10.00.1600

Running connectivity tests...

Attempting connection

[Microsoft][SQL Server Native Client 10.0]Named Pipes Provider: Could not open a connection to SQL Server [5].

[Microsoft][SQL Server Native Client 10.0]Login timeout expired

[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 allow remote connections. For more information see SQL Server Books Online.

TESTS FAILED!

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

Like (0)

Report

Is port 1433 open to the server? Have you tried using the IP address of the server as opposed to its name?

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

When you set up the ODBC - does it complete without error? I'm presuming it does because you get to launch GP and select it, and only then you get the problem?

Have you tried logging in as administrator at the TS - setting up an ODBC and launching GP?

Was this reply helpful? Yes No
Victoria Yudin 22,769 on at

Like (0)

Report
Jim,

It is not entirely clear from your posts...are you able to connect to this SQL Server from other machines? Is it just the Terminal Server having the issue or other computers as well? It sounds like the Terminal Server is the only computer you're connecting from, or the issue is everywhere. If that is the case, a number of things that I would check/try, based on your posts:

Make sure the SQL Browser Service is running on the SQL Server.

Make sure that your SQL Server allows remote connections - you can check/change this in SQL Server Management Studio, under the server properties, on the Connections page.

The error message says 'Named Pipes'. Typically you want to use TCP/IP for GP, so I would make sure that TCP/IP is enabled in SQL Server Configuration Manager.

A lot of times we see issues with connecting to a SQL Server because of the Windows Firewall. To test whether this is the issue, turn off the Windows Firewall on the SQL Server. If that allows you to connect, then you will need to add exceptions to the Windows Firewall to allow SQL Server connections.

Was this reply helpful? Yes No
Jim Lines 4 on at

Like (0)

Report

Everyone - thanks SO much for your replies. Very strange, but a colleague logged in and ran the SQLNative for x64 that is located in the very latest copy of GP2010 install files (MDGP2010_DVD_withHotfixKB2731285_ENUS.zip\MDGP2010_DVD_withHotfixKB2731285_ENUS\SqlNativeClient) and this fixed the problem.

I am baffled as to how this would have fixed the problem as the SQL Native Client 10.0 already existed on the server.

At this point I am not going to dig any further since it works.

Victoria - thank you for the very detailed bullet points, that is the road I would have gone down for trouble shooting. Actually it's EXACTLY what I was looking for even though I didn't have to use it.

If anyone has any question in the future, please respond to this post. I'll be glad to help and the answers here from Victoria, Ian, and Richard will surely help you get started in the trouble shooting process.

Thanks again for the support!!!

Was this reply helpful? Yes No