Options

SQL Compare connection issue from Vista

fullonmacfullonmac Posts: 6
edited August 28, 2007 6:58AM in SQL Compare Previous Versions
I am getting the following error connecting to a remote SQL Server database from SQL Compare 6 running on Vista Business.

"The list of databases for the specified SQL Server could not be retrieved:
A connection was successfully established with the server, but then an error occurred during the pre-login handshake.
When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections.
(provider: Named Pipes Provider, error:0 - No process is on the other end of the pipe.) "

It is nothing on the server end as I can connect fine using SQL Server Management Studio from the same computer and other users can connect to the SQL Server using other client software.

Server:
SQL Server 2005. Remote access is allowed. Only TCP/IP. Port 1433.

Client:
Vista Business. SQL Compare 6.

I do not have access to any other machines to run SQL Compare on only the one with Vista.

Any ideas? Or should I not be running this software on Vista?

Thanks in advance,
Flon

Comments

  • Options
    Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    Hi Flon,

    In the SQL 2005 configuration manager for the SQL Server conputer, does the server allow connections using TCP and named pipes? If it does allow named pipes, are both machines on the name network segment?

    You may try forcing SQL Compare to use TCP/IP instead of named pipes by entering the TCP preamble on the server name (TCP:MyServer). The .NET Framework is notorious for choosing the wrong network library to use. Also check for aliases in your client network utility or configuration manager for aliases that have the same name as your server that may be causing the connection to use named pipes.
  • Options
    I have solved the problem and it wasnt related to Vista at all, I guess I was just grasping at straws.
    It turns out the SQL Server was on a different domain than the user I was logging in as.
    If I logged in as a new local user to my computer I can connect fine.
    So it is a network/security issue.
    No idea why SSMS managed to connect and nothing else could though.

    As a contractor I had no access to the server and so had to make assumptions based on what the overly busy network admin told me.

    As we all know when problem solving, never make any assumptions / always double check things for yourself. But in some situations this is very difficult.

    Thanks for all your help.
Sign In or Register to comment.