Share
Report
1,797Up until today we were having problems with ODBC's and user logins. After installing a GP client, one could only log on to the client with sa -- but any other user received an error message, even DYNSA. Users were able to log on directly to the server without issues, but not a standard client installation.
We have separate domains for our test and production environments and sometimes have issues when traversing between them. GP initially set up its ODBC client connections with the SQL Server driver. In our experimentation we found that using the SQL Server ODBC connection, clicking on Client Configuration and manually mapping the server alias to the server's IP address would help resolve our client logon issue. However, we later experienced issues with being able to enforce GP password policies with the SQL Server ODBC. To install a new client that would enforce GP password policies we would have to create a SQL Server ODBC connection, map it to the IP address, remove the SQL Server ODBC connection, then rebuild it with a SQL Native ODBC and it would continue to work fine. (The server name to IP mapping appears to persist in the registry or some type of cache.)
Today we installed two new clients and after the long weekend we forgot about the "SQL Server ODBC server name to IP address mapping" we'd been doing. We couldn't figure out why the clients would not connect to the server with anything but sa. We started looking at the problem again and found that we administrators only had the server listed in our ODBC connection instead of server.domain.com like everyone else. Our computers continued to allow us to login since the server to IP address mapping was cached. However, we were affecting all of the other users we administrated. Whenever we set up a new user or restored a database, the server name on our machine appears to have be associated with the user's account. Since our server name did not include the domain.com like the client ODBC, the client's connection settings did not match the user's connection settings set by us and they could not log on. Once we changed the SQL Native client server names on our administrator machines to be server.domain.com and deleted/added all of the users, the new and existing client installations worked just fine.
*This post is locked for comments
All responses (
Answers (
