News: IBP 3.2.0.10735. Поддержка TIME.
Привет всем.
На сайте провайдера выложены бинарники новой сборки IBProvider (3.2.0.10735), в которой была доработана поддержка типа данных TIME. И улучшена поддержка TIMESTAMP.
Немного истории из раздела «поддержка серверных типов данных»
- В 2003(?), когда в провайдер была добавлена расширенная поддержка кодовых страниц (типа UNICODE_FSS), впервые появилась мысль — «кажется, мы поддерживаем все типы данных». Сейчас эта наивность вызывает только улыбку.
- В 2008-2009, в процессе форсированной разработки v3 (формально это был второй заход), поддержка серверных типов данных была радикально улучшена. Фактически, она вышла на современный уровень. Кода пришлось написать — немеряно. Мысль о том что «ну все, теперь точно все» появилась на пару секунд и тут же исчезла — провайдер не пропускал микросекунды типа TIME. Тема была обозначена в трекере проблем и дальнейшие работы в этом направлении были заморожены — нужно было двигаться в сторону релиза v3.
- Случайно, в процессе копания в MSDN, была обнаружена информация, которая дала конкретную надежду — проблема с TIME решаема.
Что в конечном итоге получилось.
Хотя DBTIME2 и определен как OLEDB тип, но
DBTYPE_DBTIME2 is a provider specific type that’s only available on SQLNCLI. At present, there is no plan to move it to oledb.h.
Zheng Chen. Здесь
Вообще говоря, это забавный подход — добавлять в провайдер специализированные типы данных, не отраженные в документации по OLEDB. Но хоть в документации по MSSQL есть нужные сведения.
Для того что бы обойти эти пробелы в oledb.h, в нашей библиотеке для OLEDB мы перешли на псевдонимы идентификаторов и определений типов. То, что можно — привязывается к конструкциям из oledb.h. Для DBTIME2 — определили самостоятельно. Аналогичный подход применяется и к ibase.h, а теперь вот начали изолироваться и от oledb.h.
Потом была (немного затянувшаяся) борьба с MSSQL2008. Честно говоря, настроение было весьма пессимистичным. Но, к счастью, все разрешилось. После этого из провайдера были уничтожен протезы в виде DBTIME2 с 16/7. Оставлено только правильное описание с 13/4.
Поскольку DBTIME2 не понимает ADODB, была добавлена возможность получения TIME-данных в виде WSTR-строки. До кучи, такая же возможность была добавлена для TIMESTAMP. Смотрите dbtime_rules и dbtimestamp_rules. Эти свойства можно указывать только при инициализации. «На ходу» их менять нельзя.
По-умолчанию, провайдер работает так же, как и раньше. То есть, провайдер будет терять доли секунды для TIME.
Поскольку ADODB получает TIMESTAMP через DATE, который не поддерживает доли секунды, режим «dbtimestamp_rules=2» (получать TIMESTAMP-данные в виде строки) тоже может оказаться весьма полезным.
Если клиент захочет получать TIME-данные через VARIANT, то провайдер будет упаковывать TIME в BSTR-строку. По аналогии с SQLNCLI. До этого — упаковывали время в VT_DATE.
Потом была написана гора тестов для всех мыслимых режимов работы провайдера. Как всегда — писать их просто не хочется. Но приходится себя заставлять, чтобы не было мучильно больно …
И появилась мысль — «ну все, вот теперь — точно все».
Правда, опять проскользнула мысль — «а может что-то просто не учитывается?».
Да нет, вроде все 🙂