none
[Microsoft][ODBC SQL Server Driver]Communication link failure

    Question

  • About one month ago we did a fresh install on our SQL Server, formatted everything and started with a clean OS.  Ever since then we have this random communication link failure problem.  It seems to happen completely randomly.

    [Microsoft][ODBC SQL Server Driver]Communication link failure

    Anyone have any suggestions on what causes this? The server is completely patched with all drivers up to date.

    Specs: Server 2003, SQL 2005 SP3 9.00.4035 Standard Edition


    Monday, February 15, 2010 9:50 PM

Answers

  • Hi homeguards,

    "Communication link failure” means that an existing ODBC connection was closed, and we tried to use that connection. Usually an existing connection being dropped is either a failure of a client to sent packets to keep the connection open, or intermediate network hardware dropping a connection, or SQL Server having a problem.

    To determine who is dropping the connection, we needed simultaneous network captures on both the client and SQL Server, for the few moment before the issue, and during the issue.

    Generally, we can try these things to solve the issue:
    1.Disable TCP Chimney and other Scalable Network Features per http://support.microsoft.com/kb/951037/en-us
    2.Enable the SQL Server port in Firewall.
    3.Update the Network Interface Care driver.

    If there is anything unclear, pleaes feel free to ask.

    Thanks,
    Jin Chen
    Jin Chen - MSFT
    Wednesday, February 17, 2010 8:56 AM
    Moderator

All replies


  • Here's a few questions to gather information that might help diagnose.


    What kind of frequency does the error occur roughly ?

    What kind of DSN are your clients using ?

    Are the clients running the same version of ODBC  ?

    What driver are you using (SQL Server or SQL Native client) and are you using ODBC connection pooling ?

    Have you tried re-creating the data sources ?

    Something else to help diagnose this issue is ODBC tracing if you haven't tried that already.

    Has the rebuilt server been added to the domain or network correclty (i.e. it's not an forward or reverse lookup issue, Domain Name resolution issue, or conflicting IP address) ?

    Also, (along the same lines) are you using an IP address for the server or a name ?

    Tuesday, February 16, 2010 1:48 AM

  • What kind of frequency does the error occur roughly ?
    It was happening about half the time with our MAGIC application (the IT ticket software) queried to send an email.  We moved that database off the server and now it has been running without one failure.  It has still been happening randomly with mainly our Access databases.

    What kind of DSN are your clients using ?
    SQL Server

    Are the clients running the same version of ODBC  ?
    Yup i think they are all using 2000.85.1132.00

    What driver are you using (SQL Server or SQL Native client) and are you using ODBC connection pooling ?
    All the drivers use SQL Server, not SQL Native Client. 

    Have you tried re-creating the data sources ?
    No, It is just a connection string.

    Something else to help diagnose this issue is ODBC tracing if you haven't tried that already.
    I am running these now, this is only a value on the client side correct?

    Has the rebuilt server been added to the domain or network correclty (i.e. it's not an forward or reverse lookup issue, Domain Name resolution issue, or conflicting IP address) ?
    Everything looks good, The database is using the same IP as before the format.

    Also, (along the same lines) are you using an IP address for the server or a name ?
    We are using the Server Name
    Tuesday, February 16, 2010 2:32 PM

  • What kind of frequency does the error occur roughly ?
    It was happening about half the time with our MAGIC application (the IT ticket software) queried to send an email.  We moved that database off the server and now it has been running without one failure.  It has still been happening randomly with mainly our Access databases.

    So do I understand correctly that you are no longer expiencing an issue with connectivity to SQl Server as the MS Access database is where you now see the problem, or are you using MS access as a front end talking to the SQL Sever back end?
    Also, are you saying the client and Database Server were previously co-located on the same server ?

    What kind of DSN are your clients using ?
    SQL Server

    What I meant here was Machine, User Or File DSN, but I think you were saying you aren't using a DSN anyway. Is that correct ?





    Theres a couple of other threads on this and other forums on ODBC connections being flakey, a lot of people change thier connection library to OLE DB which is more efficient anyway. I'm guessing if this was an option you would have done this already anyway.

    Another option is to look at something like this if you have to use ODBC and it warrants it:

    http://www.datadirect.com/products/odbc/odbc-sqlserver/index.ssp
    Wednesday, February 17, 2010 12:26 AM
  • Hi homeguards,

    "Communication link failure” means that an existing ODBC connection was closed, and we tried to use that connection. Usually an existing connection being dropped is either a failure of a client to sent packets to keep the connection open, or intermediate network hardware dropping a connection, or SQL Server having a problem.

    To determine who is dropping the connection, we needed simultaneous network captures on both the client and SQL Server, for the few moment before the issue, and during the issue.

    Generally, we can try these things to solve the issue:
    1.Disable TCP Chimney and other Scalable Network Features per http://support.microsoft.com/kb/951037/en-us
    2.Enable the SQL Server port in Firewall.
    3.Update the Network Interface Care driver.

    If there is anything unclear, pleaes feel free to ask.

    Thanks,
    Jin Chen
    Jin Chen - MSFT
    Wednesday, February 17, 2010 8:56 AM
    Moderator