Сдается мне, этот сервер достиг своего идеального состояния.
Только что загруженный «Developer Edition» полностью идентичен тому, который я скачивал 2018-12-13 (InterBase 2017, v13.3).
Amen.
UPD [2019-11-18]. Ан нет, шевелится — InterBase 2020. Смотрю на ссылку, а она не https. Походу, с ресурсами у них как у всех.
После прогона номинальных тестов 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;
Выпущено обновление .NET провайдера v1.14.1.
Как говорится — «нет худа без добра».
В процессе разбора проблемы с VS2019+FW4.8, нашел мелкую багу в одном из VSIX и, главное, радикально перетряхнул EXE-инсталлятор провайдера.
Если не ошибаюсь, он (EXE-инсталлятор) был написан пять лет назад. Как он работает — я уже ахез. Его какой-то мутант написал… Но сейчас (после перетряхивания) хоть станет попроще добавлять поддержку новых версий FW.
В последней VS2019 (16.2.5), после установки .NET FW4.8, перестал работать просмотр данных таблиц через наш ADO.NET провайдер. Server Explorer -> любая таблица -> контекстное меню -> загрузить данные -> пустое окно.
До установки FW4.8 (на FW4.7.2) проблем не было.
Это плохая новость.
Хорошая новость — через стандартный провайдер (System.Data.OleDb) просмотр данных тоже перестал работать.
Нужно звонить в ЖЭК и оставлять заявку.
В детстве меня покусал Джеф Рихтер, поэтому я свято верил в то, что 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 лет не тупил.
В процессе реорганизации кода получил 4 ошибки компиляции:
Ошибка C2065 ibp_task_controller_state__cancelled: необъявленный идентификатор
Ну, думаю, приплыли. Смотрю первый случай:
(далее…)
Собственно %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 Неверный дескриптор.
Оставлю это здесь.
Вчера закончился прогон всех тестов, применимых к 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.