Error 10054 firebird

Модераторы: kdv, dimitr

I just upgraded my DB to Firebird 4.0 and all seems to work when connecting to the DB using a database management tool.

So now I try to connect, after making sure I’ve upgarded my ADO.Net to FirebirdSql.Data.FirebirdClient v8.0.1 (latest).

Here is how I create my connection string (yes, db path exists and I made sure that users have modification rights):

 FbConnectionStringBuilder cs = new FbConnectionStringBuilder();
 cs.Database = @"C:/myPath/MyDB.FDB";
 cs.DataSource = "localhost";
 cs.UserID = "sysdba";
 cs.Password = "masterkey";
 cs.Dialect = 3;
 cs.Pooling = false;
 cs.ServerType = FbServerType.Default;
 // --- Omitted at first - any of the 3 types leads to errors!
 //cs.WireCrypt = FbWireCrypt.Disabled;
 var DBConn = new FbConnection(cs.ConnectionString);
 DBConn.Open();

Now, notice I left out WireCrypt option (on purpose to start with). My error is:

Error occurred during login, please check server firebird.log for details

firebird.log says:

Authentication error No matching plugins on server

So I googled around and found hints it may come from wire encryption. Well ok, so I did try all 3 versions of wire encryption — if I use Required or Enabled, I get the above error. If I use the Disabled , I get

Incompatible wire encryption levels requested on client and server

Furthermore, I tried setting WireCrypt = Disabled in firebird.conf and in my code, restarted the service and tested again — now I have the same result as with the first two cases:

Authentication error No matching plugins on server

So I guess I’m missing something here about the encryption plugins — but I couldn’t find any valuable information there, thanks for helping out!

UPDATE: here are the settings I tried and the error I got:

Attempt 1: all firebird.conf defaults (I posted it here to keep things short here):

Connection string 1:

character set=NONE;data source=localhost;initial catalog=C:UsersDBAccessMYDB.FDB;user id=SYSDBA;password=masterkey;wire crypt=Disabled

Incompatible wire encryption levels requested on client and server

Connection string 2 (wire crypt=Enabled or Required)

Authentication error No matching plugins on server

Attempt 2:

WireCrypt = Disabled

Connection string 1:

character set=NONE;data source=localhost;initial catalog=C:UsersDBAccessMYDB.FDB;user id=SYSDBA;password=masterkey;wire crypt=Disabled

Authentication error No matching plugins on server

Connection string 2 (wire crypt=Enabled) => same error!

Attempt 3:

AuthClient = Srp256, Srp
UserManager = Srp

Connection string 1:

character set=NONE;data source=localhost;initial catalog=C:UsersDBAccessMYDB.FDB;user id=SYSDBA;password=masterkey;wire crypt=Disabled

Incompatible wire encryption levels requested on client and server

Connection string 2 (wire crypt=Enabled or Required)

Authentication error No matching plugins on server

Attempt 4:

AuthClient = Srp256, Srp
UserManager = Srp
WireCryptPlugin = ChaCha, Arc4
WireCrypt = Enabled
ServerMode = Super

Connection string (same result with any wire crypt option in the connection string):

character set=NONE;data source=localhost;initial catalog=C:UsersDBAccessMYDB.FDB;user id=SYSDBA;password=masterkey;wire crypt=Enabled

Authentication error No matching plugins on server

NOTE: I also see the following message in firebird.log, which is possibly due to the service restart…

inet_error: read errno = 10054, client host = DESKTOP-1234, address = 127.0.0.1/60348, user = myusername

Последнее обновление – 21.11.2001.

Ошибки идут под буквой E (error), описание ошибки – D (description), возможное решение проблемы – как S (solution).

Описания ошибок приведены на момент существования IB 7.0. Часть ошибок могут проявляться только в предыдущх версиях (6.x, FB,Yaffil, 5.6, 5.5, 5.1, 5.0).

Внимание! Расшифровка ошибок сети на Windows для tcp/ip находится в winsock.pas/c, для UNIX – в errno.h.

E: internal gds software consistency check (partner index description not found (175))

D: «пропал» индекс первичного или вторичного ключа.
D: построен уникальный индекс по полю, по которому уже есть FK (т. е. неуникальный индекс).

S: Теоретически «пропавший» индекс можно обнаружить при помощи запроса

select R.RDB$CONSTRAINT_NAME, R.RDB$INDEX_NAME as REFINDEXNAME, I.RDB$INDEX_NAME as REALINDEX, I.RDB$RELATION_NAME, I.RDB$INDEX_INACTIVE from RDB$INDICES I RIGHT JOIN RDB$RELATION_CONSTRAINTS R on I.RDB$INDEX_NAME = R.RDB$INDEX_NAME WHERE R.RDB$CONSTRAINT_TYPE = ‘FOREIGN KEY’ or R.RDB$CONSTRAINT_TYPE = ‘PRIMARY KEY’ order by R.RDB$CONSTRAINT_NAME

Constraint без индекса (пустое поле REALINDEX) и окажется «битым». Его нужно попытаться удалить. Если удалить constraint не удается, то следует попытаться создать индекс, имя которого указано в столбце REFINDEXNAME. Уникальность индекса должна соответствовать типу constraint – уникальный для первичного ключа, и неуникальный для вторичного.

Если же речь идет о лишнем (уникальном) индексе, то один из индексов рекомендуется удалить.

E: gds__free: attempt to release bad block
E: gds__alloc: memory pool corrupted

D: какие-то проблемы с памятью, или некорректно работающей UDF.

S: Решение проблемы неизвестно.
S: В более ранних версиях IB (4.2 и ниже) эта ошибка была известна как баг 8349, проявлявшийся при больших размерах файла сортировки. Т. е. при наличии запросов, обрабатывающих большие объемы данных, и имеющих сортировку ORDER BY без соответствующего индекса.

Кроме того, ошибка может появляться в multithread-приложениях из-за закрытия соединения не в том thread, в котором оно было открыто.

E: WNET/wnet_error: ReadFile end-of-file errno = 109 (win)
E: INET/inet_error: send errno = 10054 (win)
E: Inet/inet_error: send errno=104 (unix)

D: обрыв клиентского соединения. WNET – по NetBEUI, INET – по TCP/IP.

S: Для начала надо сделать upgrade на максимально последнюю версию IB (например, для 5.x это 5.6, для 6.x это 6.0.1.6 или 6.5, для Firebird – релиз v1 и так далее). Затем убедиться, что на сервере, если это NT (или W2K), стоит самый последний Service Pack. Если клиенты – NT (или W2K) Workstation, то на них поставить тот же сервиспак, что и на сервере. Если клиенты – Windows 95/98, то скачать с www.microsoft.com самые последние обновления для netbeui и tcp/ip.

Вообще при работе по tcp/ip таких ошибок должно быть существенно меньше, чем по netbeui.

Собственно, слово WNET в сообщении об ошибке означает ошибку при работе по протоколу по netbeui (строка вида \serverc:dirdata.gdb), а INET – по протоколу tcp (строка вида server:c:dirdata.gdb).

Если ошибки 109 или 10054 продолжают появляться, то нужно искать дефектное сетевое оборудование – хаб, свитчер, или сетевую карту. Теоретически в этом может помочь использование какого-либо SNIFFER, но методика пока неизвестна. Также см. утилиту ibconsvc.zip, которая заносит информацию о коннектах и дисконнектах (только tcp) прямо в interbase.log, что позволяет отследить станции или хабы, генерирующие ошибку 10054.

Почти то же самое написано в документе: http://community.borland.com/article/0,1410,25340,00.html

Еще один вариант, который иногда помогает устранить обрывы коннектов – изменение параметров CONNECTION_TIMEOUT и DUMMY_PACKET_INTERVAL в IBCONFIG (или isc_config на UNIX) на значения, отличные от умолчательных, например, 170 и 50 соответственно. В некоторых случаях на UNIX помогает установка connection_timeout в 0.

E: INET/inet_error: accept errno = 10093
E: INET/inet_error: read errno = 10038

D: ошибка при попытке инициализации подсистемы tcp/ip (NetBEUI), вызвана частыми появлениями ошибок 10054 (109). Как правило после этой ошибки сервер аварийно завершает работу. Для перезапуска сервера возможно требуется рестарт NT.

S: решение такое же, как и для ошибок 10054 или 109 (см. выше).

E: SCH_validate — not entered
E: SCH_validate — wrong thread

D: неверно работающая UDF

S: скорее всего, если функция написана на Delphi (Pascal), то в модуле не указано IsMultiThread:=True. Т. е. библиотека должна быть проинициализирована для безопасной работы с несколькими threads, поскольку сервер обращается к DLL UDF именно из разных threads.
Также следует избегать использования threadvars на серверах с двумя и более процессорами, т. к. в коде Delphi (по крайней мере 4) есть ошибки с использованием TLS. Вместо threadvars рекомендуются прямые вызовы функций работы с TLS в Win32.

E: Page 34672 is an orphan

D: возможно, что при операциях записи на диск сервер завершил работу аварийно или произошел сбой системы по питанию

S: Ничего не нужно делать. Осиротевшие страницы (orphan pages) будут использованы повторно для размещения новых данных.

E: internal gds software consistency check (error during savepoint backout (290))

D:

S:

E: internal gds Software consistency check (size of opt block exceeded (286))

D:

S:

E: internal gds software consistency check (invalid SEND request (167))

D:

S:

E: internal gds software consistency check (decompression overran buffer (179))

D: обычно ошибка возникает при попытке прямого копирования базы данных с одной платформы на другую, например, из-под NT на Netware.

S: перенос баз данных между платформами должен производиться только путем backup/restore. Если ошибка возникла при backup, то необходимо сделать проверку базы данных при помощи gfix с проверкой record fragments, и после этого опять попытаться сделать backup (возможно с опцией ignore checksum errors).

E: internal gds software consistency check (Too many savepoints (287))

D: возникает при большом количестве insert/update/delete (явном или косвенном, через триггеры) в одной длительной транзакции. Возможно влияние количества вызываемых триггеров и процедур в этой транзакции.

S: в компоненте соединения с БД (например, IBDatabase) нужно указать параметр isc_tpb_no_auto_undo. В этом случае сервер не будет пытаться сохранять все изменения через механизм savepoints. Делать это следует только для тех коннектов, где заранее известно, что количество изменений в одной из транзакций будет большим (явно или через триггеры, по количеству изменяемых записей – больше 10-100 тысяч).

E: internal gds software consistency check (wrong record length (183))

D: может возникнуть при UPDATE полей, по которым построен unique индекс.

S: ошибка исправлена в IB 5.6 (bugs N 60135, 60537).

Здравствуйте!Столкнулась с такой проблемой. Есть программа, которая многопоточно обращается к локальной БД. (Сервер FireBird)
Данная программа стоит у многих пользователей. Но только у одного программа перестает коненктится к БД, потому что FireBird сервер зависает. И пока его не перезапустишь, ничего не работает. В логах FireBird очень часто пишется
INET/select_wait: select failed, errno = 10054
Чуть реже
INET/select_wait: select failed, errno = 10053
INET/select_wait: select failed, errno = 10055

Еще реже
SRVR_multi_thread/RECEIVE: error on main_port, shutting down
Shutting down the Firebird service with 63 active connection(s) to 2 database(s)
REMOTE INTERFACE/gds__detach: Unsuccesful detach from database.
Uncommitted work may have been lost
и очень редко
terminated abnormally (4294967295)

В логах программы
EIBInterBaseError Unable to complete network request to host «@1».
Error writing data to the connection.
Удаленный хост принудительно разорвал существующее подключение.

Кто может сказать в чем тут проблема:в программе,в сети,в FireBird или еще в чем-то и как это можно лечить?
FireBird у всех пользоваетелей один,программа из одного инсталятора ставится
Версия Firebird 2.1
Спасибо!

Вот такой пример сегодня по логам
В логах программы
23.06.2011 12:25:48 [Err] Unable to complete network request to host «@1».Error writing data to the connection.Удаленный хост принудительно разорвал существующее подключение. EIBInterBaseError (тут идет запрос к БД,она уже не доступна)

23.06.2011 12:26:02 [Err] UnInitializeDB -> EIBInterBaseError Unable to complete network request to host «@1».Error writing data to the connection.
Удаленный хост принудительно разорвал существующее подключение.(Закрываем программу)

в это же время в логах FireBird
OP_LININSKIY2 (Server) Thu Jun 23 12:25:04 2011
SRVR_multi_thread/RECEIVE: error on main_port, shutting down

OP_LININSKIY2 (Server) Thu Jun 23 12:25:45 2011
Shutting down the Firebird service with 63 active connection(s) to 2 database(s)

OP_LININSKIY2 (Server) Thu Jun 23 12:25:45 2011
The database ххх was being accessed when the server was shutdown

OP_LININSKIY2 (Server) Thu Jun 23 12:25:45 2011
The database ххх was being accessed when the server was shutdown

OP_LININSKIY2 (Client) Thu Jun 23 12:25:46 2011
INET/inet_error: read errno = 10054

OP_LININSKIY2 (Client) Thu Jun 23 12:25:48 2011
INET/inet_error: read errno = 10054

OP_LININSKIY2 (Client) Thu Jun 23 12:25:48 2011
INET/inet_error: send errno = 10054

OP_LININSKIY2 (Server) Thu Jun 23 12:25:56 2011
Shutting down the Firebird service with 1 active connection(s) to 1 database(s)

OP_LININSKIY2 (Server) Thu Jun 23 12:25:56 2011
The database ххх was being accessed when the server was shutdown

OP_LININSKIY2 (Client) Thu Jun 23 12:26:01 2011
INET/inet_error: send errno = 10054

OP_LININSKIY2 (Client) Thu Jun 23 12:26:01 2011
INET/inet_error: send errno = 10054

OP_LININSKIY2 (Client) Thu Jun 23 12:26:02 2011
INET/inet_error: send errno = 10054

OP_LININSKIY2 (Client) Thu Jun 23 12:26:02 2011
INET/inet_error: send errno = 10054

OP_LININSKIY2 (Client) Thu Jun 23 12:26:02 2011
INET/inet_error: send errno = 10054

OP_LININSKIY2 (Client) Thu Jun 23 12:26:02 2011
INET/inet_error: send errno = 10054

OP_LININSKIY2 (Client) Thu Jun 23 12:26:02 2011
INET/inet_error: send errno = 10054

OP_LININSKIY2 (Client) Thu Jun 23 12:26:02 2011
INET/inet_error: send errno = 10054

OP_LININSKIY2 (Client) Thu Jun 23 12:26:02 2011
INET/inet_error: send errno = 10054

OP_LININSKIY2 (Client) Thu Jun 23 12:26:02 2011
INET/inet_error: send errno = 10054

OP_LININSKIY2 (Client) Thu Jun 23 12:26:02 2011
INET/inet_error: send errno = 10054

OP_LININSKIY2 (Client) Thu Jun 23 12:26:02 2011
REMOTE INTERFACE/gds__detach: Unsuccesful detach from database.
Uncommitted work may have been lost

OP_LININSKIY2 (Client) Thu Jun 23 12:26:02 2011
INET/inet_error: send errno = 10054