Миф №2. OLEDB не позволяет воспользоваться всеми преимуществами сервера.

За те 10 лет, что я вожусь с OLEDB, я все сильнее склоняюсь к мысли, что OLEDB больше предназначено для IB/FB, чем для MSSQL. Что говорит о незаурядных способностях его авторов. Да ладно, скажу прямо — его спроектировал МЕГА МОЗГ, не обремененный ограничениями окружающей действительности 96 (или 98?) года.

Из существующих ограничений, вот так вот с ходу, я могу вспомнить только одно — провайдер не позволяет пользователю подготавливать команду в одной сессии, а выполнять в другой. Сессия — это объект для управления транзакциями. Хотя и позволяет это делать в рамках одной сессии, но в её разных (последовательных) транзакциях. Правда за 10 лет лично я практически ни разу не испытывал потребности в такой фиче — переброс команды между сессиями. И никто о ней не спрашивал :). Если «спросят» — реализуем нестандартный интерфейс.

Серверные типы данных

Какие угодно. И как угодно. И прямо в данный момент (закончив v3.2) я даже уверен, что это соответствует действительности. До этого была одна назойливая мысль про дробные части секунд — они не вписывались в DBTYPE_DBTIME. Но с приходом MSSQL2008 и его новым DBTYPE_DBTIME2 проблема решена. На всякий случай, мы добавили еще получение TIME-данных и в текстом виде (см свойство dbtime_rules).

Из фич:

  • Текстовые блобы с кодовой страницей OCTETS обрабатываются как бинарные блобы.
  • Мега навороченная поддержка массивов. Поверьте, провайдер работает с ними лучше чем сам сервер. Я вообще люблю этот тип данных. Жаль только, что с массивами у сервера остаются два неприятных бага.
  • Ну и, конечно, наш локальный мега-конвертор типов данных. Одно из лучших вложений нашего времени, сделанных под перспективу.

Запросы

Я так полагаю, провайдер сможет пропустить любой тип запроса к серверу. Даже «CREATE DATABASE» и «DROP DATABASE». Более того, за счет внутреннего парсера, у IBProvider-a нет, к примеру, детских болезней с DDL запросами и именованными параметрами.

Нюансов тут много. Например, «маркеры» кодовых страниц. Это я про _win1251 ‘русский текст’. Или работа в NONE-подключении с объектами, в названии которых есть национальные символы. Надеюсь у нас они все явно учитываются и поддерживаются.

Транзакции

Несколько транзакций в рамках одного подключения — запросто. Говорите — ADODB не может? Ну, во-первых, это не OLEDB, а надстройка над ним. А во-вторых — все таки может.

Нестандартный уровень изоляции — через запрос «SET TRANSACTION …» можете определить то, что вам нужно.

Обработка ошибок

Ну да, статус вектор мы не даем пощупать. Зато вот (спасибо пользователям) выдаем SQLSTATE для всех типов серверов. Не только для FB2.5, в котором появилась их поддержка, но и для всех версий IB/FB.

Насчет статус вектора — ну если очень надо, то в OLEDB прописано где и как это делается.

Остальное

Из остального — в голову приходя только события. Я надеюсь, мы доберемся и до них — многое из необходимого уже реализовано и работает внутри провайдера. Например, пул потоков.

Если еще чего то нет, или работает плохо, дык мы же не сидим сложа руки. Пишите, обсудим 🙂

Эпилог, или как там это называется. Нет, конечно, никто не запрещает создать плохую реализацию OLEDB. За примером далеко ходить не надо — в CVS дереве Firebird-а лежит одно такое творчество. Шедевр, однозначно. 15(?) файлов — и весь провайдер. Блин, а у нас — более 15MB исходного кода 🙁

Оставить комментарий