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) тоже будут работать. Не знаю кому как, а мне прямо захорошело 🙂
Псевдонимы имен OLEDB свойств
Захотел прикрутить к источнику данных IBProvider нестандартный интерфейс с методом GetPropertyInfo — идентичный IDBProperties::GetPropertyInfo, но возвращающий в DBPROPINFO::pwszDescription мультистроку с основным именем свойства и его псевдонимами.
Ну чтобы клиент мог работать с псевдонимами наравне с основным именем.
И получил облом.
Если у источника данных запрашивать нестандартный интерфейс, то стандартный пул подключений OLE DB умывает руки и этот источник данных не кэшируется.
Блин, реально печалька.
Поддержка SRP224, SRP256, SRP384, SRP512
В новом триале IBProvider (сборка 31426) добавлена поддержка новых методов аутентификации Firebird 3.0.4: SRP224, SRP256, SRP384, SRP512.
Понятное дело, речь идет про собственного клиента для Firebird.
SRP256 поддерживается по-умолчанию и определен как первичный способ аутентификации.
Остальные методы можно задействовать через свойство инициализации remote:auth.
Вести с полей
В Entity Framework Core опять перепахали весь ландшафт. Состыковать провайдер с изменениями, в смысле восстановить компилируемость, было относительно не сложно. А вот более 3 тысяч сбойных тестов (~90%) конкретно удручают.
Хотя надо во всем искать положительные стороны.
Например, благодаря этому «небольшому» исследовательскому проекту появился IBProvider v5 и устранены мелкие проблемы в .Net Provider.
Даже как-то забавно рассматривать возню с EFCore как плату за улучшения в основных проектах.
Исследование исходного кода Firebird
Ну очень похоже на:
MSSQL и Firebird Embedded
Где-то на краю сознания мне давно хотелось попробовать подключиться к базе данных Firebird через MSSQL Linked Server и встроенный Firebird.
Ну хотелось и хотелось (мало чего в голову лезет).
А сегодня это хотение озвучил один наш клиент. Пришлось пробовать. С Firebird 2.5.8.
Не получилось.
В логе Firebird вылезли такие ошибки:
HOME4 Thu May 09 20:23:52 2019 OpenProcessToken failed. Error code: 5 HOME4 Thu May 09 20:23:52 2019 Operating system call OpenProcess failed. Error code 5
Такие дела.
UPD [2019-05-16]. Кстати, клиент написал, что осилил. Одним из затыков была необходимость копирования модулей ICU в system32. Сам я так и не добил этот вопрос 🙂