IBProvider v3.50 вышел на финишную прямую. По крайней мере, мне так кажется. В новой тестовой сборке (28330), доступной для скачивания с сайта, обновлена обработка ошибок.
Первое. Наконец-то, реализована нормальная поддержка предупреждений. Предыдущий код «забывал» их в случае возникновения критической ошибки.
Второе. В операциях с массовой генерацией предупреждений и ошибок, при превышении жестко заданного лимита на их количество (128 штук), добавляется сигнальное сообщение о том, что часть сообщений будет проигнорирована. Раньше провайдер начинал молча игнорировать ошибки сверх нормы.
—
Сейчас по плану добавление поддержки «INSERT … RETURNING» в обновляемых множествах. Собственно сам код этой поддержки уже написан. Нужно выспаться запилить тесты. Много тестов. Жестоких.
И наступит гармония и умиротворенность.
Последнюю пару месяцев я настолько активно мучал «Araxis Merge», что даже засылал его разработчикам «feature requests».
В последней выпуске (2018.4988) одна их хотелок была удовлетворена — появилась возможность открывать окно «Windows Expolorer» с расположением сравниваемого файла/каталога.
Однако пост не про это. А про то, как запускать этого сравнивателя из «Total Commander» для объектов, выбранных в левой и правой панели. Я это сделал через кнопку на панели инструментов:
1. Щелкаем в тотале на панели инструментов правой кнопкой мыши.
2. Выбираем «Change …».
3. Указываем расположение файла Merge.exe — «C:\Program Files\Araxis\Araxis Merge\Merge.exe».
4. Пишем параметры запуска — %X%P%S %T%R.
5. Закрываем окно настройки кнопки по «OK».
Все, теперь выбираем что будем сравнивать в левой и правой панели и жмем на нашу кнопку запуска Merge.exe.
Должно работать.
На сайт IBProvider загружен новый триал OLE DB провайдера — v3.50.0.28072, в котором исправлена структурная ошибка внутреннего представления данных из за которой были специфические затруднения с модификацией базы данных.
Суть проблемы заключалась в том, что провайдер не умел корректно обрабатывать DEFAULT-значения (они обрабатывались как NULL-значения). Для этого нужно было вместо пары {value, IsNull} работать с парой {value, Status}.
В новой сборке это досадное ограничение устранено и теперь IBProvider умеет передавать состояние данных через все свои слои — от верхнего до нижнего.
В самом низу с DEFAULT-значениями умеет работать только Firebird 2.5+ (и то очень ограничено). В FB2.5 появилась поддержка запроса:
INSERT INTO ... DEFAULT VALUES
Вот этот запрос теперь и используется при добавлении новых записей в «обновляемых» множествах.
На примере работы с провайдером через связанных сервер MSSQL это выглядит так: (далее…)
В задумчивости тыкая в интерфейсе «OLE DB Rowset Viewer» (это стандартная штука для проверки провайдеров «руками и глазами»), запросил неправильный интерфейс результата и спровоцировал ассерт внутри ICommand::Execute. Релизный бинарник, как положено, возвращает E_NOINTERFACE.
Изучение этой проблемы показало, что ассерт был по делу — FAILED-ошибки (типа E_NOINTERFACE) должны обрабатываться другой веткой кода, в которой (до кучи) освобождаются сформированные значения OUT-параметров.
То есть, получалось, что ICommand::Execute возвращал OUT-параметры и FAILED-код. Это вполне могло приводить к тому что клиент, видя FAILED-ошибку, мог забить на освобождение значений OUT-параметров. А это, в свою очередь, приводит к утечке ресурсов.
Вот такая вот головоломка.
А все почему — не были написаны тесты, проверяющие реакцию ICommand::Execute на неправильные параметры.
Так что пришлось, ругаясь, устранять проблему, создавать необходимые тесты и выпускать незапланированное обновление IBProvider — v3.49.1.
Обнаружил интересное обсуждение — «Не используйте дети malloc в Windows 10».
Вкратце — похоже в Win10 поломали кучи и теперь они глючат в многопоточных приложениях.
Попробовал — действительно падает.
При Обаме Балмере такого не было!
Загружены бинарные файлы второго обновления IBProvider в текущем году (во завернул) — v3.49.0.27783.
Изменения.
1. Запрещено использование DBBINDING с типами DBTYPE_EMPTY, DBTYPE_NULL.
2. Задействованы коды ошибок DB_E_UNSUPPORTEDCONVERSION, DB_E_BADSTATUSVALUE, DB_E_BADTYPE.
3. Уборка мусора в коде. Проводил в последний путь корзину файл с утилитами, созданный в 2000 году. Даже немного взгрустнулось.
4. Продолжил избавляться от использования классов, порожденных от std::ostream, std::istream.
5. Устранил баги и странный код, обнаруженные PVS-студией.
6. Ревизия и нормализация кода.
В целом, текущий выпуск это всего лишь подготовительный этап к следующей четвертой версии (3.50), в которой будет обновлен базовый компонент провайдера — структура DBVARIANT.
UPD [2018-03-15]. Опубликованы новости на сайте.
Привет всем.
Пару месяцев назад обратил внимание, что 64-битный бинарник IBProvider-а (собранный в 2017-ой) внезапно потяжелел на полторы сотни килобайт. Я еще подумал — «это с какого перепугу произошло?». Было сильное подозрение, что «это» произошло после очередного обновления студии, но так и не проверил.
Сегодня обновил 2017-ю студию до версии 15.6.1 и вижу следующее:
Наверное, к лету.
Оказывается я пропустил весьма занятную новость.
Announcing the new release of OLE DB Driver for SQL Server
Previously, Microsoft announced deprecation of the Microsoft OLE DB Provider for SQL Server, part of the SQL Server Native Client (SNAC). At the time, this decision was made to try to provide more simplicity for the developer story around Windows native software development as we moved into the cloud era with Azure SQL Database, and to try to leverage the similarities of JDBC and ODBC for developers. However, during subsequent reviews it was determined that deprecation was a mistake because substantial scenarios within SQL Server still depend on OLE DB and changing those would break some existing customer scenarios.
With this in mind, we have decided to undeprecate OLE DB and release a new version by the first quarter of calendar year 2018 March 2018
Dmitry Kovalenko on 21 февраля, 2018 | 1 Comment
Под новый год забрел в книжный магазин и унес с собой сабжевую книженцию. Ностальгия и все такое. У меня была первая редакция этой книги 🙂
Иногда полистываю, на ночь глядя.
Ближе к концу книги есть хороший совет:
Всегда инициализируйте указатели в конструкторах и всегда обнуляйте указатель после освобождения памяти, на которую он указывает. Эти действия лишними не бывают.
Вспомнились баги Firebird 2.5, в котором этим правилом пренебрегали.
Спокойных вам кошмаров снов.
Привет всем.
Через 18 лет (радует что не 20) сформировалось полное понимание назначения типов данных DBTYPE_EMPTY и DBTYPE_NULL.
DBTYPE_EMPTY обозначает отсутствие значения как такового. Указание данных с типом DBTYPE_EMPTY — это сигнал использовать значения по умолчанию. Это же самое что указать статус данных DBSTATUS_S_DEFAULT.
DBTYPE_NULL обозначает NULL-состояние данных. Это же самое что указать статус данных DBSTATUS_S_ISNULL.
Зачем нужно дублирование DBTYPE_EMPTY/DBTYPE_NULL и DBSTATUS_S_DEFAULT/DBSTATUS_S_ISNULL?
Типы используются в языках вроде VB/C# с доступом к провайдеру через ADODB/ADO.NET. Там есть предопределенные значения empty/null (VB) и null/DBNull.Value (C#). Просто присваиваете эти значения и провайдер получит сигнал использовать DEFAULT или NULL значение для параметра/колонки.
А статусы используются при работе с провайдером напрямую — вы подготавливаете многократно используемый «буфер для обмена данных» с указанием «нормальных» типов данных параметров/колонок, а потом, в зависимости от ситуации, выставляете статусы DBSTATUS_S_OK/DBSTATUS_S_ISNULL/DBSTATUS_S_DEFAULT передаваемым значениям.
С парой DBTYPE_NULL/DBSTATUS_S_ISNULL IBProvider нормально работает уже давно.
А вот с DBTYPE_EMPTY/DBSTATUS_S_DEFAULT — пока полный косяк.
