Frequently Occured Error "80004005" When Connecting to SQL Server 2005 Via ADO OLE DB


  • I'm connecting to SQL Server 2005 via ADO OLE DB.

    At client side, the programming language is C++, and client OS is Windows Vista Business 32-bit, with Windows DAC 6.0, version 6.0.6000.16386. The SQL Server is MS SQL Server 2005 Enterprise Edition with SP3.
    The connection string I used is " Provider=sqloledb;Server=remote SQL Server;DataBase=some DB;UID=user;PWD=pwd ".

    There are about 20 threads running concurrently, each of them connects to a same database in a remote SQL Server, the related information is:

    Code = 80004005;Code meaning = Unspecified error; Source = Provider

    and this error is induced by follow code:

    csConnectionString( " Provider=sqloledb;Server=remote SQL Server;DataBase=some DB;UID=user;PWD=pwd " );
    _ConnectionPtr m_pConn;   
    _CommandPtr m_pCmd;      
    HRESULT hr;
    m_pConn->ConnectionTimeout = 10;              
    _bstr_t bstrSRC( csConnectionString );                              
    hr = m_pConn->Open(bstrSRC,_T(""),_T(""),-1);     //  _com_error exception thrown

    I have tried following methods to solve my problem:

    Method 1: Change Connection String
    Using ODBC instead of OLE DB, the connection string is modified as:
    Driver=SQL Server
    ;Server=remote SQL Server;DataBase=some DB;UID=user;PWD=pwd
    However, another error occurs:

    Code = 80004005, Code meaning =
    Unspecified error , Source = Microsoft OLE DB Provider for ODBC Drivers, Description = [Microsoft][ODBC SQL Server Driver]communication links fail

    I've done a lot of search but find no clues.

    Method 2:  Update System
    Install all patches for Windows Vista. After that, it became even worse, exception is thrown almost every hour, and the description is:

    Code = 80004005, Code meaning = Unspecified error , Source = Microsoft OLE DB Provider for ODBC Drivers, Description = [Microsoft][ODBC SQL Server Driver]communication links fail

    , which is identical to above one .

    Method 3: Check System Logs:
    I have checked both logs of Windows Vista at client side and logs of SQL Server 2005 at server side, there seems nothing related to my problem.

    What shall I do to
    resolve it? Thank you very much
    • Edited by Jason.Smith Friday, June 26, 2009 5:48 PM fixing double encoding in title
    Tuesday, June 16, 2009 5:40 AM


All replies

  • Hi,
    1.How do you use connection. Do the 20 thread use the same connection or every thread has their own thread?
     2.Please try OLEDB SNAC Provider to check whether the issue still happen
    3.can you share you reproduce code to us, so that we can reproduce it locally.
    4.If it is not easy to reproduce, it is better to collect call stack to us, we can do further investigation.
    Tuesday, June 16, 2009 6:36 AM
  • Can you please follow the link to troubleshoot?

    Just tell us the first step you see issues. 

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Tuesday, June 16, 2009 9:32 PM
  • As mentioned by Gabriel, could you use single-thread to see whether the problem exist or not? This can narrow down the problem a lot.

    Could you try the C++ example for ADO at: (pay special attention at the function OpenX)

    Also, could you try to use SNAC OleDB and then enable Bid Trace ( See whether there are any error messages in the log. If any, post it here.

    btw, What's your project status (deployed, under development, etc.)? If it is still at the early stage, we recommend customers to use ODBC for native languages (say, C++). And ADO is mainly used in script languages, say ASP.

    WDAC Team, Microsoft.

    Pak-Ming Cheung - MSFT
    Monday, June 22, 2009 2:06 PM
  • Usually, ADO applications leverages connection pooling and call will not actually invoke real connection(thus should not meet communication links failure).
    Could you please check, with SQL Server Profiler, whether the application keeps creating new SQL Server connections(i.e., it doesn't re-use existing ones)?

    Wednesday, June 24, 2009 5:48 AM
  • 1. Try use SNAC OLEDB provider to see if the problem will repro.
    2. Using fewer threads to see if the problem will repro.
    You can follow Zheng's instruction to get the infomation from SQL Profile. I guess it's caused by too much connections created on the server.
    Friday, June 26, 2009 7:50 AM