08s01 odbc sql server driver ошибка связи

Mark SQL 1.11
MS SQL Server 2005

Несколько дней у пользователей на разных рабочих местах при работе в MARK SQL вываливаются периодичекси окна с ошибками:

SQL Error
State: ’08S01′
Message:[Microsoft][ODBC SQL Server Driver]Ошибка связи
Query: Select caption, query, coldwidths, colnames, retval, from, exdicts

SQL Error
State: ’08S01′
Message:[Microsoft][ODBC SQL Server Driver]Ошибка связи
Query: SELECT RDR_ID FROM READERS WHERE RDR_ID=’04098’

SQL Error
State: ‘01000’
Message:[Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionWrite(send())
Query: SELECT INV_ID FROM INV WHERE T876p=’02384’

SQL Error
State: ‘01000’
Message:[Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionRead(recv())
Query: Select ires from dbres where name=’FictDoc’

Причем ошибки в разных базах, в разных местах программы. Например, при вызове поиска по всем справочникам, вызове справочника студентов, при попытке сохранить карточку новой книги. Повторная попытка открыть справочник вызывает эту же ошибку. Если закрыть программу и открыть заново все работает.

Перезагрузили SQL Server, не помогло.

Источник

RRS feed

  • Remove From My Forums

  • Question

  • I’m getting this error in a VMWare ESX environment.  The application establishes a new connection for each transaction (yes, I know that’s not a good idea) but subsequent transactions generally succeed after I get a few of these failures. 

    I’m opening a support incident with VMWare, since it doesn’t seem to occur in a non-virtual environment, but I thought I’d post here too in case someone has seen something similar.

    Thanks for your help,
    Martin

All replies

  • We’re seeing the same thing as we’re supporting a company that runs an application that creates a new connection for each command.

    Their hardware setup is a Dell 1800 w/Dual 3GHz Xeons and raid array, connected to a Cisco 2948 catalyst switch for network.

    The database is running the 2005 version of msde… SQL Express i believe.

    A host of errors they get… at least a few times a day

    Error: 08S01 — Communication link failure

    Error: 01000 — ConnectionWrite (send())

  • I have the same issue. Got any solution.

  • I have the same issue at around 1400 connections to SQL.   Any resolution?

  • We have the same errors.. «Communication link failure» often preceeded by the «ConnectionWrite(send())» error.  This is on a 3rd party application so we don’t know the internals of how it functions.  Suspect that it likewise creates a new connection for each command but not really sure.

    The application runs on multiple app servers and they connect to a dedicated database server.

    Database server is 64 bit Server 2003 with 64 bit SQL 2005, 4 dual core processors, and 16 GB RAM.

    We have looked at almost everything and cannot isolate the problem or find a solution.

    Any suggestions would be appreciated.

  • I’ve got a customer with the same issue. They are the only customer I have running the queries over the WAN.

    I had one example where trying to connect to one SQLServer server I got the message. Trying to connect to another server, did not get the problem. Rebooting the client machine solved (and typically solves) this problem.

    If anyone has info on this, it would be greatly appreciated. Doesn’t look like this question’s getting much attention.

  • I got a similar message. I’m working on a VM and it says OLE DB error: OLE DB or ODBC error: Communication link failure; 08S01; Shared Memory Provider: No process is on the other end of the pipe.
    ; 08S01.

    When I try to process an Analysis Services cube.

    Any ideas anyone?

  • Same here, please respond if there is any available solution.

  • I have an application that uses ADO to create recordsets on the fly and throw them away after reading data, using one connection object.

    If used on a local

    SQL Server 2005, the communication link failure occures when network connection broke down between two uses of recordsets. The temporary disrupted network connection (eg. WLAN) has nothing to do with the communication between application and server (local), and the connection is not broken at the time the error occures. This can be reproduced by temporary disconnecting any network connection.

    The property Connection.Connected is still true after network connetcion failed temporary. So my workaround is to catch up the error at Recordset.Open, reconnect if Error.SQLState is 08S01 (setting

    Connection.Connected to false and true), and try again.

  • Martin, i know this is a very very old thread but we are seeing this same issue. Did VMWare ever help on the issue (you had said you had a case open with them)? Brent

  • TruckinITGuy (Brent)…  Did you ever determine a cause and get a fix for this?  We are having the same problem on ESX.  I found another article that suggested changing the value of SynAttackProtect (below).  We probably have that set
    to 1 for better security, I am going to try to set that back to 0 and see if that helps.  But if you made headway, I would appreciate knowing how.  Jeff


    The following parameters can be used with this registry value:

    • 0 (default value): No SYN attack protection
    • 1: Set SynAttackProtect to 1 for better protection against SYN attacks. This parameter causes TCP to adjust the retransmission of SYN-ACKS. When you set SynAttackProtect to 1,
      connection responses time out more quickly if the system detects that a SYN attack is in progress. Windows uses the following values to determine whether an attack is in progress:

      • TcpMaxPortsExhausted
      • TCPMaxHalfOpen
      • TCPMaxHalfOpenRetried

  • I know this thread is old.  Did anyone ever get this issue resolved?  I am experiencing the same issue with VM running on ESXi 3.5 and the system had been running fine since 2008. Nothing has changed in the system, but users are getting disconnected
    several times a day from our ERP system for two weeks now. SQL 2005 SP3 On Windows 2003 64 Bit.

    ra

    • Proposed as answer by

      Monday, October 28, 2013 5:48 PM

  • We are also getting the out of memory error when processing an AS cube that had previously run fine.

      «OLE DB error: OLE DB or ODBC error: Communication link failure; 08S01; Communication link failure; 08S01; Shared Memory Provider: No process is on the other end of the pipe.»

    The Windows System Event Viewer Log revealed a ‘Resource-Exhuastion-Detector’ Warning:

        «Windows successfully diagnosed a low virtual memory condition. The following programs consumed the most virtual memory: sqlservr.exe (1280) consumed 13694660608 bytes, msmdsrv.exe (5464) consumed 10279247872 bytes, and Ssms.exe (4032)
    consumed 775794688 bytes.»

    We are expanded the PageFile on the VM and will see if that helps.  We are also rebooting the server and performing delayed monthly maintenance, so that may also contribute to the solution.

    The lack of memory has also caused the MSSQLSERVEROLAPService to crash and stop itself. 

        «The description for Event ID 22 from source MSSQLServerOLAPService cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the
    component on the local computer.

       If the event originated on another computer, the display information had to be saved with the event.

       The following information was included with the event:

       Internal error: An unexpected exception occurred.

       the message resource is present but the message is not found in the string/message table»

    ———-

    UPDATE: Expanding the PageFile on the VM seemed to have resolved the problem.  The AS Cube processed successfully.

    • Proposed as answer by
      ColSanders
      Tuesday, October 29, 2013 10:55 PM
    • Edited by
      ColSanders
      Wednesday, October 30, 2013 3:54 AM

Источник

Our high volume native (C++) data processing application is experiencing intermittent dysfunction in one or more ODBC data access threads when reading or writing a BLOB from a table, and in particular experiences dysfunction in the ODBC connection
in use by one or more threads when the problem occurs.

The SQL State returned by ODBC (GetDiagRec) is 08S01, which according to documentation is an indication of SQL connection dysfunction.  

[Microsoft][ODBC Driver 13 for SQL Server] The connection is no longer usable because the server response for a previously executed statement was incorrectly
formatted

We don’t think the information we are collecting in association with this SQL State and the connection failure is indicative of the true nature of the problem.  In our native service applications, we are configuring a shared ODBC environment with a
per-driver connection pool.  As near as I can determine from documentation, this means we have one connection pool shared by all data access threads per service application (per-process), because there is only one driver in use.

We have concerns that we may be responsible for this failure by calling SQLEndTran with SQL_ROLLBACK on a connection handle in this shared environment in our data access threads, when a BLOB read failure occurs, leading to the SQLEndTran call.  Specifically,
we have concerns about what the following ODBC documentation really means:

Note

SQLEndTran cannot be used to commit or roll back transactions
on a shared environment. SQLSTATE HY092 (Invalid attribute/option identifier) will be returned if SQLEndTran is called with Handle set to either the handle of a shared environment or the handle of a connection
on a shared environment.

What this documentation seems to imply is that manual commit transactions are not supported on pooled ODBC connections and bad things will happen if you call SQLEndTran on these connection handles.  This is a very big deal.

Our code is doing exactly what is described here — calling SQLEndTran on a connection handle in a shared environment.  However, we do not see SQLSTATE HY092 when the problem occurs and a pool connection appears to die.  Instead, we see 08S01. 
 In addition, we do not encounter SQL_ERROR when we call SQLEndTran with SQL_COMMIT on any connection handle in any of the hundreds of thousands of successful BLOB read and write calls we make each day.  So it would appear to us that SQLEndTran with
SQL_COMMIT on a connection handle in a shared environment may be benign, whereas SQLEndTran with SQL_ROLLBACK may not be benign, and may kill the pool connection.

We also have irrefutable evidence that one or more connections in our shared environment pool remain dysfunctional after each 08S01, and cause thousands of repeated data access failures as they are (apparently) served up by the driver manager in subsequent
calls in data access threads.

Could someone please comment on, or explain the ODBC documentation note shown above, and on its potential relation to our problem?

Thanks in advance…

  • Edited by

    Tuesday, January 7, 2020 7:07 PM

Источник

RRS feed

  • Remove From My Forums

  • Question

  • I’m getting this error in a VMWare ESX environment.  The application establishes a new connection for each transaction (yes, I know that’s not a good idea) but subsequent transactions generally succeed after I get a few of these failures. 

    I’m opening a support incident with VMWare, since it doesn’t seem to occur in a non-virtual environment, but I thought I’d post here too in case someone has seen something similar.

    Thanks for your help,
    Martin

All replies

  • We’re seeing the same thing as we’re supporting a company that runs an application that creates a new connection for each command.

    Their hardware setup is a Dell 1800 w/Dual 3GHz Xeons and raid array, connected to a Cisco 2948 catalyst switch for network.

    The database is running the 2005 version of msde… SQL Express i believe.

    A host of errors they get… at least a few times a day

    Error: 08S01 — Communication link failure

    Error: 01000 — ConnectionWrite (send())

  • I have the same issue. Got any solution.

  • I have the same issue at around 1400 connections to SQL.   Any resolution?

  • We have the same errors.. «Communication link failure» often preceeded by the «ConnectionWrite(send())» error.  This is on a 3rd party application so we don’t know the internals of how it functions.  Suspect that it likewise creates a new connection for each command but not really sure.

    The application runs on multiple app servers and they connect to a dedicated database server.

    Database server is 64 bit Server 2003 with 64 bit SQL 2005, 4 dual core processors, and 16 GB RAM.

    We have looked at almost everything and cannot isolate the problem or find a solution.

    Any suggestions would be appreciated.

  • I’ve got a customer with the same issue. They are the only customer I have running the queries over the WAN.

    I had one example where trying to connect to one SQLServer server I got the message. Trying to connect to another server, did not get the problem. Rebooting the client machine solved (and typically solves) this problem.

    If anyone has info on this, it would be greatly appreciated. Doesn’t look like this question’s getting much attention.

  • I got a similar message. I’m working on a VM and it says OLE DB error: OLE DB or ODBC error: Communication link failure; 08S01; Shared Memory Provider: No process is on the other end of the pipe.
    ; 08S01.

    When I try to process an Analysis Services cube.

    Any ideas anyone?

  • Same here, please respond if there is any available solution.

  • I have an application that uses ADO to create recordsets on the fly and throw them away after reading data, using one connection object.

    If used on a local

    SQL Server 2005, the communication link failure occures when network connection broke down between two uses of recordsets. The temporary disrupted network connection (eg. WLAN) has nothing to do with the communication between application and server (local), and the connection is not broken at the time the error occures. This can be reproduced by temporary disconnecting any network connection.

    The property Connection.Connected is still true after network connetcion failed temporary. So my workaround is to catch up the error at Recordset.Open, reconnect if Error.SQLState is 08S01 (setting

    Connection.Connected to false and true), and try again.

  • Martin, i know this is a very very old thread but we are seeing this same issue. Did VMWare ever help on the issue (you had said you had a case open with them)? Brent

  • TruckinITGuy (Brent)…  Did you ever determine a cause and get a fix for this?  We are having the same problem on ESX.  I found another article that suggested changing the value of SynAttackProtect (below).  We probably have that set
    to 1 for better security, I am going to try to set that back to 0 and see if that helps.  But if you made headway, I would appreciate knowing how.  Jeff


    The following parameters can be used with this registry value:

    • 0 (default value): No SYN attack protection
    • 1: Set SynAttackProtect to 1 for better protection against SYN attacks. This parameter causes TCP to adjust the retransmission of SYN-ACKS. When you set SynAttackProtect to 1,
      connection responses time out more quickly if the system detects that a SYN attack is in progress. Windows uses the following values to determine whether an attack is in progress:

      • TcpMaxPortsExhausted
      • TCPMaxHalfOpen
      • TCPMaxHalfOpenRetried

  • I know this thread is old.  Did anyone ever get this issue resolved?  I am experiencing the same issue with VM running on ESXi 3.5 and the system had been running fine since 2008. Nothing has changed in the system, but users are getting disconnected
    several times a day from our ERP system for two weeks now. SQL 2005 SP3 On Windows 2003 64 Bit.

    ra

    • Proposed as answer by

      Monday, October 28, 2013 5:48 PM

  • We are also getting the out of memory error when processing an AS cube that had previously run fine.

      «OLE DB error: OLE DB or ODBC error: Communication link failure; 08S01; Communication link failure; 08S01; Shared Memory Provider: No process is on the other end of the pipe.»

    The Windows System Event Viewer Log revealed a ‘Resource-Exhuastion-Detector’ Warning:

        «Windows successfully diagnosed a low virtual memory condition. The following programs consumed the most virtual memory: sqlservr.exe (1280) consumed 13694660608 bytes, msmdsrv.exe (5464) consumed 10279247872 bytes, and Ssms.exe (4032)
    consumed 775794688 bytes.»

    We are expanded the PageFile on the VM and will see if that helps.  We are also rebooting the server and performing delayed monthly maintenance, so that may also contribute to the solution.

    The lack of memory has also caused the MSSQLSERVEROLAPService to crash and stop itself. 

        «The description for Event ID 22 from source MSSQLServerOLAPService cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the
    component on the local computer.

       If the event originated on another computer, the display information had to be saved with the event.

       The following information was included with the event:

       Internal error: An unexpected exception occurred.

       the message resource is present but the message is not found in the string/message table»

    ———-

    UPDATE: Expanding the PageFile on the VM seemed to have resolved the problem.  The AS Cube processed successfully.

    • Proposed as answer by
      ColSanders
      Tuesday, October 29, 2013 10:55 PM
    • Edited by
      ColSanders
      Wednesday, October 30, 2013 3:54 AM

Источник

@mathieuk I noticed two cases:

  1. When «— SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} —» is handled properly, there is «+++ killed by SIGKILL +++» in response and the worker (php artisan queue:work) end.

Strace

vagrant@dev:/var/www/e2$ strace -e 'trace=!all' php artisan queue:work --queue=default --timeout=10 --tries=1
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13324, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
[2019-01-11 14:49:44] Processing: AppJobsCreateJob
Start!
Query!
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
+++ killed by SIGKILL +++
Killed

Error Log

[2019-01-11 14:49:54] local.ERROR: AppJobsCreateJob has been attempted too many times or run too long. The job may have previously timed out. {"exception":"[object] (Illuminate\Queue\MaxAttemptsExceededException(code: 0): App\Jobs\CreateJob has been attempted too many times or run too long. The job may have previously timed out. at /var/www/e2/vendor/laravel/framework/src/Illuminate/Queue/Worker.php:394)
  1. When it’s not handled properly, nothing happens, the worker is not killed and is doomed. Whenever a new Job arrives, it gets the link failure exception.

Strace

vagrant@dev:/var/www/e2$ strace -e 'trace=!all' php artisan queue:work --queue=default --timeout=10 --tries=1
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=13120, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
[2019-01-11 14:31:59] Processing: AppJobsCreateJob
Start !
Query !
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
[2019-01-11 14:32:09] Failed:     AppJobsCreateJob
[2019-01-11 14:33:25] Processing: AppJobsCreateJob
Start !
Query !
[2019-01-11 14:33:25] Failed:     AppJobsCreateJob
[2019-01-11 14:34:08] Processing: AppJobsCreateJob
Start !
Query !
[2019-01-11 14:34:08] Failed:     AppJobsCreateJob
[2019-01-11 14:36:39] Processing: AppJobsCreateJob
Start !
Query !
[2019-01-11 14:36:39] Failed:     AppJobsCreateJob
[2019-01-11 14:48:30] Processing: AppJobsCreateJob
Start !
Query !
[2019-01-11 14:48:30] Failed:     AppJobsCreateJob

Error Log

[2019-01-11 14:32:09] local.ERROR: SQLSTATE[08S01]: [Microsoft][ODBC Driver 17 for SQL Server]Communication link failure (SQL: insert into [failed_jobs] ([connection], [queue], [payload], [exception], [failed_at]) values (beanstalkd, default, {"displayName":"App\Jobs\CreateJob","job":"Illuminate\Queue\CallQueuedHandler@call","maxTries":null,"timeout":null,"timeoutAt":null,"data":{"commandName":"App\Jobs\CreateJob","command":"O:18:"App\Jobs\CreateJob":9:{s:29:"u0000App\Jobs\CreateJobu0000className";s:35:"App\Jobs\CreatableJob\GrosseRequete";s:24:"u0000App\Jobs\CreateJobu0000args";a:0:{}s:6:"u0000*u0000job";N;s:10:"connection";N;s:5:"queue";N;s:15:"chainConnection";N;s:10:"chainQueue";N;s:5:"delay";N;s:7:"chained";a:0:{}}"}}, PDOException: SQLSTATE[08S01]: [Microsoft][ODBC Driver 17 for SQL Server]TCP Provider: Error code 0x2714 in /var/www/e2/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:142
[2019-01-11 14:33:25] local.ERROR: SQLSTATE[08S01]: [Microsoft][ODBC Driver 17 for SQL Server]Communication link failure (SQL: insert into [failed_jobs] ([connection], [queue], [payload], [exception], [failed_at]) values (beanstalkd, default, {"displayName":"App\Jobs\CreateJob","job":"Illuminate\Queue\CallQueuedHandler@call","maxTries":null,"timeout":null,"timeoutAt":null,"data":{"commandName":"App\Jobs\CreateJob","command":"O:18:"App\Jobs\CreateJob":9:{s:29:"u0000App\Jobs\CreateJobu0000className";s:35:"App\Jobs\CreatableJob\GrosseRequete";s:24:"u0000App\Jobs\CreateJobu0000args";a:0:{}s:6:"u0000*u0000job";N;s:10:"connection";N;s:5:"queue";N;s:15:"chainConnection";N;s:10:"chainQueue";N;s:5:"delay";N;s:7:"chained";a:0:{}}"}}, PDOException: SQLSTATE[08S01]: [Microsoft][ODBC Driver 17 for SQL Server]Communication link failure in /var/www/e2/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:142
Источник

Понравилась статья? Поделить с друзьями:

Не пропустите эти материалы по теме:

  • Яндекс еда ошибка привязки карты
  • 08eb ошибка пежо 207
  • 092 910 ошибка принтера xerox 5021
  • 0894 ошибка мерседес акпп
  • 092 910 ошибка xerox 5024

    • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии