Из недостатков использования Ole Db провайдера в .Net могу выделить следующее: * Для взаимодействия с Ole Db используется стандартные классы System.Data.OleDb и они не полностью поддерживают возможности того же Firebird. К примеру CommitRetain/RolbackRetain возможно вызвать только через SQL запрос. Это конечно не смертельно, но в качестве примера в самый раз.
* Не поддерживаются именованные параметры. т.е они как бы живут в OleDbParamerersCollection, но на проверку в Ole Db провайдер передаются только по индексу без имен. С этим связан ряд неудобств. * Код классов System.Data.OleDb пытается претендовать на универсальность и далеко не самый производительный. Он так же использует не всю спецификацию Ole Db. Не факт, что сами напишем лучше :) но по крайней мере идеи для этого есть. Достоинства * более производительное решение на основе С++ по сравнению с managed кодом. Хотя то, что находится над провайдером :) (ADO .Net) может свести на нет это преимущество. * возможность использовать Ole Db провайдер не только в .Net (об этом было в заключении обзора) * относительно простая возможность изменить базу данных за счет смены Ole Db провайдера без необходимости кардинальной переделки кода. Лучшем решением было бы написать своего .Net провайдера над Ole Db. Чесно говоря, такие мысли нас посещают давно и часто. :) а пока сами довольствуемся тем, что предлагает Microsoft
