Post reply

-2147467259 - [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.

  • August 31, 2010 at 2:35 pm

    #144943

    Hi,

    We have SQL Server 2005 x64 EE with SP3 on 2 node a/p cluster on Windows 2003. Our application connects to SQL Server named instance as below:

    SQLVS\INS1.Here the port is dynamic.

    But some times (once in a while), the application is unable to communicate with the SQL Server and getting the below error on Application Server:

    Error Application D:\Program Files\ABCDLL\Log\error.log: Thread ID: 1436 ,Logged: | pZDAL.cZDAL:1.6.72.ExecuteCommand | 08-19-2010 12:22:64

    Error Application D:\Program Files\ABCDLL\Log\error.log: Thread ID: 1436 ,Logged: | 06/11/2009 | #222400 | SKM

    Error Application D:\Program Files\ABCDLL\Log\error.log: Thread ID: 1436 ,Logged: | Refactoring for Out of Memory Issues

    Error Application D:\Program Files\ABCDLL\Log\error.log: Thread ID: 1436 ,Logged: | -2147467259 - [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.

    But there are NO errors on SQL Server box.

    I went through the below link where it address the same error:

    http://support.microsoft.com/kb/888228

    But how to know whether the application is connecting to a SQL Server named instance by using TCP/IP sockets or not?

    To fix this issue, do we need to use Static IP and connect the SQL Server instance using SQLVS\INS1:port?

    And also, I noticed the error "Refactoring for Out of Memory Issues". Is that mean the application server has did NOT have enough Memory?= and which in turn causing failure to connect SQL Server?

    Are the errors dependent or they separate?

    Please advice. Thanks

  • August 31, 2010 at 2:41 pm

    #1214601

    pshaship (8/31/2010)

    But how to know whether the application is connecting to a SQL Server named instance by using TCP/IP sockets or not?

    To fix this issue, do we need to use Static IP and connect the SQL Server instance using SQLVS\INS1:port?

    And also, I noticed the error "Refactoring for Out of Memory Issues". Is that mean the application server has did NOT have enough Memory?= and which in turn causing failure to connect SQL Server?

    Are the errors dependent or they separate?

    I use SQL Profiler to get a quick check to see if the application is attempting a connection. You can also enable successful logon in SQL temporarily to see if it getting connected or failing. I would expect that the issue is probably on the application side.

    Shawn Melton
    Twitter: @wsmelton
    Blog: wsmelton.github.com
    Github: wsmelton

  • August 31, 2010 at 4:11 pm

    #1214635

    This error occurs once or twice in a week and I need to run the profiler for 1 week continuously to capture the connection which may not be feasible (I mean running the profiler for 1 week)

    Is there any other way to capture what causing the error?

    I also noticed the memory error "Refactoring for Out of Memory Issues". What does this mean for an application?

  • August 31, 2010 at 6:10 pm

    #1214657

    From the below MS link

    http://support.microsoft.com/kb/888228

    This problem occurs during the discovery phase of the connection. The IPSec policy on the client drops packets from the server when the source IP changes

    In above statement, Is the source SQL Server ?

    What is the Source IP change here we taking about? Please advice..

    Even though the SQL Server Port is Dynamic, it's port NEVER changed after reboots or failovers..

    Thanks

  • August 31, 2010 at 7:49 pm

    #1214684

    pshaship (8/31/2010)

    This error occurs once or twice in a week and I need to run the profiler for 1 week continuously to capture the connection which may not be feasible (I mean running the profiler for 1 week)

    Is there any other way to capture what causing the error?

    Yes that is true in your instance it is probably not an option to run Profiler. However, you can create a server-side trace that may be something to look into. You can filter down to particular events (logon/logoff) and to a particular username/logon that can dramatcially keep the trace file to a small size.

    Shawn Melton
    Twitter: @wsmelton
    Blog: wsmelton.github.com
    Github: wsmelton

  • August 31, 2010 at 7:59 pm

    #1214686

    Since the application is the one throwing the error I would probably start with the documentation or vendor on the memory error you are receiving.

    I would take a look at the root KB dealing with this issue as well: http://support.microsoft.com/kb/328306

    This one actually looks like something to check: http://support.microsoft.com/kb/318432/[/url]

    Shawn Melton
    Twitter: @wsmelton
    Blog: wsmelton.github.com
    Github: wsmelton

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply