Решил прогнать на кодовой базе v5 модульные тесты встроенного клиента к Firebird. В качестве жертв были выбраны FB3.0.4 и FB2.5.6.
100 лет уже эти тесты не запускал — ограничивался основными тестами. Они тоже неплохо так разные варианты перебирают.
В процессе перезапуска тестов на FB2.5.6 (дорабатывал их устаревший код) нарвался на тупняк сервера со списками запросов. Ну, думаю, сейчас тройку замучаю и если на ней тест «RemoteFB.WORK.013.StmtAllocate.v2.ptype__lazy_send.011.check_release_of_dropped_stmts» тоже будет тупить — держите меня семеро.
(далее…)
Сегодня официально выпущен IBProvider v5.
А двадцать лет назад была зарелизена штука, с которой все началось:
База работала на InterBase 5.x. IB4 мои идеи уже не тянул.
После 55-го обновления, сломалась инициализация источника данных через пул подключений и ibp-файл с параметрами.
То есть, с помощью строки подключения вида «file name=employee.ibp». Где employee.ibp — это UTF8-файл со строкой инициализации IBProvider.
UDL-файлы не поломаны и с ними проблем нет. (далее…)
Возникла забавная ситуация, в которой неправильное решение более притягательно, чем правильное. Отчасти «потому что могу».
В OLE DB запрещен вызов метода IDBInitialize::Uninitialize, если у источника данных есть открытые дочерние объекты (сессии, команды, наборы рядов).
It is an error to call IDBInitialize::Uninitialize when there are open sessions, commands, or rowsets on the data source object; that is, the consumer must release all interface pointers on all sessions, commands, and rowsets on the data source object before calling IDBInitialize::Uninitialize.
Я бы тут вместо «open» написал бы «not released», но поскольку дальше русским по-белому написано «the consumer must release all interface pointers on all sessions, commands, and rowsets on the data source object», то вроде как всякая двусмысленность исчезает.
Есть еще аналогичный метод IDBDataSourceAdmin::DestroyDataSource.
Any open OLE DB objects on this data source, such as sessions, commands, rowsets, rows, and views, must be released before calling this method.
IBProvider v3 кладет на эти правила и разрешает эти операции при наличии у Data Source дочерних объектов. Но к этому я вернусь чуть попозже.
Если собираетесь читать дальше, то приготовьте пару стаканов…
(далее…)
Внезапно обнаружились баги в инсталляторе провайдера — после деинсталляции 32-битной версии переставала работать 64-битная версия. И наоборот.
Проблема была связана с ProgID — эти записи в реестре общие для 32-битных и 64-битных компонент. Исправил.
Сначала была мысль забить переиздать v3.55, но потом я вспомнил что у меня «валяется без дела» полностью оттестированная v3.55.1. И решил выложить её.
В инсталляторе есть еще пара изменений.
2. Все инсталляторы (vc10-vc15) теперь используют MSM-ы c VS CRT. То есть тупое копирование DLL с VS CRT осталось в прошлом.
3. Бинарник с COM-объектами из примеров провайдера теперь ставится в каталог «PF/LCPI/IBProvider.Common/bin».
Изменения в самом IBProvider я описал здесь.
UPD. А, ну да. В инсталлятор «Free IBProvider» добавлена установка бинарника с COM-объектами из примеров. Вот.
Собственно сам (бесплатный) компилятор от BCB5 я перестал мучать где-то в апреле 2010 года.
Бинарник он собирал, но этот бинарник не работал. Какие-то проблемы с генерацией C++ исключений.
Но вот его make.exe я вполне себе успешно продолжал использовать для сборки IBProvider из командной строки.
Если штука работает, то зачем её менять?
У этого make.exe тоже был заскок в виде «Fatal: Command too long» при генерации строки длинее 32 килобайт.
Вылазила эта проблема не очень часто, поэтому как-то раньше её терпел — нужно просто разбить генерируемую строку на две.
Но сегодня, когда эта «Command too long» опять вылезла, понял, что уже я уже устал от всего этого.
И переключился на make.exe из свеженького бесплатного компилятора от Emb, который я обнаружил и скачал где-то полгода назад 🙂
У него этой 32-килобайтной херни нет.
Правда вылезла другая охинея — make.exe генерирует строку без перевода каретки. А компиляторы студии не любят командные строки длиннее 128 килобайт (если я все правильно помню — я эти эксперименты ставил давно).
Как добавить в строку перевод каретки я не догнал.
Поэтому счастье в полном объеме как не было так и нет.
Но зато, будем считать, замена build-системы IBProvider отложена на неопределенное время 🙂
Dmitry Kovalenko on Январь 23, 2019 | 1 Comment
С утра задергали, чуть не забыл 🙂
Я вот думаю, надо уточнить — 18 января 2000 года я понял, что OLE DB провайдер таки придется писать.
Бо к тому моменту я уже наелся своими поделками на тему COM-интерфейсов для доступа к InterBase и уже понимал, что крупный проект (который только предстояло писать) они явно не потянут.
Так что сегодня 19 лет как я решился создать эту штуку.
Дури много тогда было, да.
UPD. 6940 дней 🙂
На нем можно выполнить очень полезный запрос:
select CURRENT_DATE-CAST('<дата вашего рождения>' AS DATE) FROM RDB$DATABASE
И узнать сколько вам сегодня стукнуло дней.
Я свои 15000 дней очень хорошо отметил.
А сегодня пойду отмечать 25000 дней своего старика 🙂
Оставлю здесь ссылку на эту заметку про Hyper Threading.
Чтобы долго её не искать, когда у меня снова появятся мысли — «может включить его у себя?«.
… которая будет очень долго вызывать у меня тоску по времени, бездарно потраченному на глупые решения:
pDataSource->m_spDsState.swap(spOpenedState); //no throw
