Внезапно обнаружились баги в инсталляторе провайдера — после деинсталляции 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
В новой тестовой сборке IBProvider (v3.55.1.29284) исправлена очень древняя ошибка, связанная с непониманием различия между состоянием источника данным и состоянием подключения.
Как следствие, вместо проверки состояния источника данных (здесь достаточно определить сам факт перехода в инициализированное состояние) проверялось состояние подключения (в общем случае это приводит к дерганью сервера).
Проверка состояния источника данных выполняется в методах IDBProperties, которые могут вызываться относительно часто.
По идее, это исправление делает ненужным свойство инициализации check_cn_status.
Не прошло и двадцати лет. Только девятнадцать.
Уже очень хочется от них избавиться.
И начать писать по-настоящему интересные программы с «enum class» и «variadic templates».
Наверное уже можно поздравить всех, кто сюда заглядывает, с наступающим Новым 2019-ым Годом!
И это, простите меня, если что 🙂
Dmitry Kovalenko on 30 декабря, 2018 | 1 Comment
… пришла в больную голову. ОРЗ или что-то вроде того, блин.
Я тут как-то тут писал что в сетевых пакетах (гоняемых между сервером и клиентом) первым делом нужно указывать их длину.
Ну, чтобы его можно было целиком выбирать пакет из потока без анализа его данных.
Сейчас этого (в FB) нет, и как результат плохо работает отмена выполнения операции (op_cancel).
Еще можно в пакеты включать последовательно генерируемый ID, для более точного управления. Но это так. Мысль не про это.
Мысль про то, что в последнем байте нужно засылать флаг подтверждения завершения отправки пакета. Какие могут быть варианты значений этого флага:
— Ноль, если все ok и пакет таки надо обработать.
— Единица, если пакет нужно выкинуть. К примеру, в процессе его отправки клиент передумал и решил его отменить.
Не знаю, хорошая эта мысль или плохая. Но зафиксировать её стоит.
