Подключение к FB 2.x через собственного клиента IBP

После прогона номинальных тестов IBProvider с FB2.5.9, обнаружил в логе сервера множество записей вида

VXP2-FB02-5-9 Sat Sep 28 22:09:35 2019
SERVER/process_packet: connection rejected for DIMA.-1.-1

Ошибок на уровне самих тестов не наблюдается.

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

Он сначала пробует подключаться с использованием 13-го протокола. А потом предлагает подключиться через «12,11,10».

Можно было сразу предлагать «13,12,11,10», как это делает fbclient.dll, но там есть вопросы к надежности.

Для избежания «промахов» с 13-ым протоколом в строке подключения можно явно указать используемый протокол — 12.

А для устранения «промахов» с TCP/IP v6, которые нигде не отображаются, но приводят к тормозам подключения, надо еще явно указать использование TCP/IP v4.

То есть, строка подключения должна выглядеть приблизительно так:

location=inet4://server_name/d:\database\employee.fdb;remote:protocol=12;

ADO.NET провайдер v1.14.1

Выпущено обновление .NET провайдера v1.14.1.

Как говорится — «нет худа без добра».

В процессе разбора проблемы с VS2019+FW4.8, нашел мелкую багу в одном из VSIX и, главное, радикально перетряхнул EXE-инсталлятор провайдера.

Если не ошибаюсь, он (EXE-инсталлятор) был написан пять лет назад. Как он работает — я уже ахез. Его какой-то мутант написал… Но сейчас (после перетряхивания) хоть станет попроще добавлять поддержку новых версий FW.

Сломался просмотр данных в VS2019+FW4.8

В последней VS2019 (16.2.5), после установки .NET FW4.8, перестал работать просмотр данных таблиц через наш ADO.NET провайдер. Server Explorer -> любая таблица -> контекстное меню -> загрузить данные -> пустое окно.

До установки FW4.8 (на FW4.7.2) проблем не было.

Это плохая новость.

Хорошая новость — через стандартный провайдер (System.Data.OleDb) просмотр данных тоже перестал работать.

Нужно звонить в ЖЭК и оставлять заявку.

Interlocked функции для Int64 и WinXP

В детстве меня покусал Джеф Рихтер, поэтому я свято верил в то, что Interlocked-функции экспортируются системной DLL-ю.

В сгенерированный машинный код для вызова этих функций я не заглядывал.

Как следствие, я считал что версии для 64-битных чисел на старой WinXP не поддерживаются и использовать их нельзя…

Этому способствовало и описание этих функций. Например, InterlockedExchange64:

Minimum supported client Windows Vista [desktop apps | UWP apps]
Minimum supported server Windows Server 2003 [desktop apps | UWP apps]
Target Platform Windows

А тут внезапно обнаружилось, что эти функции (по большому счету) не экспортируются, а встраиваются в точку вызова.

Это радикально все меняет!

        return static_cast<_Ty>(_InterlockedIncrement64(_Atomic_address_as<long long>(this->_Storage)));
000000013F40ABC2  mov         rcx,qword ptr [this]  
000000013F40ABC9  call        std::_Atomic_address_as<__int64,std::_Atomic_padded<unsigned __int64> > (013F3FA5CCh)  
000000013F40ABCE  nop  
000000013F40ABCF  mov         ecx,1  
000000013F40ABD4  lock xadd   qword ptr [rax],rcx  
000000013F40ABD9  inc         rcx  
000000013F40ABDC  mov         rax,rcx  

Приведенный код нормально отрабатывает на 32-битной XP SP2.

Написал бы Рихтер про это в своем третьем издании «Win для Pro» — я бы 20 лет не тупил.

Проклятый Intellisense

В процессе реорганизации кода получил 4 ошибки компиляции:

Ошибка C2065 ibp_task_controller_state__cancelled: необъявленный идентификатор

Ну, думаю, приплыли. Смотрю первый случай:
(далее…)

9 лет назад был зарелизен IBProvider v3

Собственно %subj%.

Было море адреналина и непрекращающийся допаминовый резонанс.

Я рад, что эта дата отмечается с пятой версией IBProvider на руках 🙂

Вести с полей

Не знаю, что там случилось с сервером FB3.0.4 (а может с базой), но тесты заклинило и в firebird.log вижу следующее:

HOME4	Mon Aug 12 08:28:46 2019
	Database: D:\DATABASE\RAM\IBP_TEST_FB30_D3_2.GDB
	internal Firebird consistency check (pointer page vanished from DPM_next (249), file: dpm.cpp line: 1904)

HOME4	Mon Aug 12 08:28:46 2019
	Database: D:\DATABASE\RAM\IBP_TEST_FB30_D3_2.GDB
	internal Firebird consistency check (pointer page vanished from DPM_next (249), file: dpm.cpp line: 1904)

HOME4	Mon Aug 12 08:29:47 2019
	I/O error during "WriteFile" operation for file "D:\DATABASE\RAM\IBP_TEST_FB30_D3_2.GDB"
	Error while trying to write to file
	Неверный дескриптор. 

HOME4	Mon Aug 12 08:29:47 2019
	Database: D:\DATABASE\RAM\IBP_TEST_FB30_D3_2.GDB
	I/O error during "WriteFile" operation for file "D:\DATABASE\RAM\IBP_TEST_FB30_D3_2.GDB"
	Error while trying to write to file
	Неверный дескриптор. 

Оставлю это здесь.

Большое тестирование IBP 5.5.1 и FB 3.0.4

Вчера закончился прогон всех тестов, применимых к IBProvider v5 и Firebird v3. 27 дней, Карл.

Тестировался FB 3.0.4 (Win, x64, SuperServer). Официальная сборка с firebirdsql.org. С FB v3.0.5 почему-то не сложилось — файл базы данных выжирал все доступное место на рам-диске (80GB) и кино заканчивалось. Я три недели «помучался» и откатился на 3.0.4. Возможно я где-то что-то не то сделал…

В предыдущий раз тоже «мучался» FB3.0.4. Но сейчас тесты гонялись на IBProvider v5, Win10 (1809+) и у процессора включен HT (я его включил после обновления биоса). (далее…)

Вести с полей

Выложены обновления IBProvider v5.5.1 и «LCPI OLE DB Services» v1.9.

Предмет гордости — «LCPI OLE DB Services» собирается с нулевым количеством предупреждений 4-го уровня. Четвертого, Карл!

Аналогичный подвиг в отношении IBProvider не осилил. Нужно будет думать. Зато изничтожил все предупреждения третьего уровня.

Из «интересностей» — устранение предупреждений в коде вида:

char* b;
char* e;
//....
std::fill(b,e,0); //<--- приведение int (0) к char

Заменил 0 на structure::zero — это «волшебный» объект, который возвращает ноль нужного типа. Типа std::nullptr.

std::fill(b,e,structure::zero);

Схожие проблемы есть с -1. Для этого числа в библиотеке есть structure::negative_one.

Еще подчистил иерархию классов исключений в библиотеке — обнаружились какие-то непонятные задумки и «оптимизации» молодости.

В целом, сборка с 4-ым уровнем предупреждений — это очень неплохой способ оценки кода. Рекомендую.

Поскольку сюда заглядывают боги, добавлю, что выпуск был протестирован с Firebird 3.0.5.33139, в который попал отрефакторенный SHA2.

VS2019 (C++) и Windows XP SP2

Некоторые виды проверок IBProvider осуществляются на виртуальной машине с древней Windows XP SP2.

Ставлю я туда сборки vc12xp (VS2013, XP Mode).

А сегодня что-то в голове щелкнуло и решил попробовать туда поставить сборки vc16 (VS2019).

Работают!

Я так удивился, что тут же попробовал туда поставить сборки vc15 (VS2017) — не работают. Вылазит ошибка, связанная с MSVCP140.dll.


Я прямо загорелся идеей изничтожить весь этот зоопарк студий (VS2008-VS2017) на компьютере и оставить только 2019-ю 🙂


UPD1. Если поставить на XPSP2 рантайм от VS2019 (14.20.27508.00001), то сборки провайдера vc15 (VS2017) тоже будут работать. Не знаю кому как, а мне прямо захорошело 🙂