Leave feedback
  • Question

    SQL Server does not exist or access denied

Enter a new topic
  • Christofer Lindqvist Christofer Lindqvist StreamServe Employee
    0 likes 3130 views

    Hi,

    I have a problem where the installation of StreamServe Enterprise Repository fails with the error message "SQL Server does not exist or access denied". Any help appreciated.

    Environment:
    StreamServe SP4R2 on a Win2008Server.
    SQL2005 on a Win2003Server cluster.
    SQL has two instances. The first instance (been used as a single SQL server for a while) is running on default port 1433 and is called NAME3\INSTANCE (NAME3=DNS name for the clustergroup). The second instance created for StreamServe is called NAME4 (NAME4=DNS name for the clustergroup)and uses port 1440.

    The problem appears when trying to start the installation and connecting to the NAME4 SQL instance, it just doesn’t find the server. If this is because of that the SQL instance is running on a different port than then default SQL port, because the server not being published on the network correctly or something else, we can’t really say.

     

    I feel we have looked at almost every angle possible:

    -          All services up and running correctly, SQL Server, SQL Browser etc.

    -          Connecting via the installation to NAME4 – Doesn’t work.

    -          Connecting via the installation to the first SQL instance, NAME3\INSTANCE – Works OK.

    -          Connecting via the installation from another Windows 2008 Server – Doesn’t work.

    -          Connecting via the installation from a Windows 2003 Server – Doesn’t work.

    -          Running installation on my local machine with port set to 1440 – Works OK.

     

    So connecting to any other SQL instance or server from the Windows 2008 Server where we want to do the installation works fine, but whenever we try to connect to the SQL instance that we should use, we fail. Meaning we have a problem with that specific instance for some reason. We verified that the StreamServe installation doesn’t have a problem installing on an SQL Server where another port than the default port is used, so it shouldn’t be the installation itself that fails.

     

    There are a couple of things I see might be the cause of the problem:

    -          A firewall or antivirus software are blocking the connections on port 1440. Either outgoing on the 2008 Server where we want to do the installation from, or incoming on the actual SQL Server. Unfortunately we couldn’t do this test as we didn’t have the appropriate rights, or knowledge, to dig any deeper into this.

    -          The actual SQL instance is somehow set up in the wrong way, or not being published correctly. We could on the other hand connect to the instance via SQLCMD for example but I don’t know if that tells us anything.

    -          Problems with an SQL instance on a cluster?

     

    Regards,
    Christofer

     

    Tuesday 14 September, 2010
  • Best Answer
    Christofer Lindqvist Christofer Lindqvist StreamServe Employee
    0 likes

    Updating this with the answer for the problem.

    This was due to that an SQL Server default instance has to have the default port.

    In our case we hade NAME3 as default instance running port 1433, then installed another instance called NAME4. NAME3 got an instance name (NAME3/INSTANCE) and NAME4 was set with port 1433 and without instance name.

    Apparently you shouldnt use the default port number for anything other than the default instance.

    Regards,
    Christofer

    Wednesday 26 September, 2012
  • Vyv Lomax Vyv Lomax Administrator
    0 likes

    Have you enabled the tcp protocol in Surface Area Configuration?

    Have you mixed mode login available?

    Are you using SA or another user? If other user then please state access rights.

    Can you use the telnet host port command and get a login?

    Thursday 16 September, 2010
  • Christofer Lindqvist Christofer Lindqvist StreamServe Employee
    0 likes

    Yes, yes, yes and yes.

    If we extract the scripts and run them locally on the SQL machine there is no problem, so the user is ok. If we continue with the framework installation it will fail due to the same problem though. Telnet to the host and port 1440 works fine.

    When browsing for the server (instead of typing the servername) it doesnt find our server which might be a little strange. But it doesnt find the other instance either, and there we can connect with the installation.

    What i feel is strange is that the original installation was made several months ago, then called NAME3. When setting up our instance the original installation was renamed to NAME3\INSTANCE but our instance is only called NAME4. Dont know anything about how setting up SQL instances work but in my mind the original would still be called NAME3 (or NAME3\INSTANCE1) and our instance NAME4\INSTANCE2.

    Thursday 16 September, 2010
  • Vyv Lomax Vyv Lomax Administrator
    0 likes

    Is SQL Browser service running?

    Thursday 16 September, 2010
  • Christofer Lindqvist Christofer Lindqvist StreamServe Employee
    0 likes

    Yes it is. That was my first thought as well.

    Read something about that SQL browser could have some problems when running on a cluster, but i dont see that this should be the problem since we cant find the first instance either, but we can connect to that one.

    Thursday 16 September, 2010
  • Stefan Cohen Stefan Cohen StreamServe Employee Administrator
    0 likes

    moved to Administration

    Tuesday 21 September, 2010
  • Christofer Lindqvist Christofer Lindqvist StreamServe Employee
    0 likes

    Updating this with the answer for the problem.

    This was due to that an SQL Server default instance has to have the default port.

    In our case we hade NAME3 as default instance running port 1433, then installed another instance called NAME4. NAME3 got an instance name (NAME3/INSTANCE) and NAME4 was set with port 1433 and without instance name.

    Apparently you shouldnt use the default port number for anything other than the default instance.

    Regards,
    Christofer

    Wednesday 26 September, 2012