Dimitry Sibiryakovsphinx_mvНу, и в какие фичи (и, самое главное - какой) реляционной СУБД не
укладывается ADO.NET?
В любые фичи, отсутствующие в MS SQL.
Б.С.К.
ADO.NET ни разу не завязан на конкретный тип СУБД. То есть - категорически!
Dimitry Sibiryakov Параллельные транзакции,
Какие СУБД их поддерживают?
В каких случаях параллельные транзакции полезны и применяются?
В чем их преимущество перед пулом соединений с единственной отдельной транзакцией для каждого соединения из пула?
И кто запрещает в провайдере ADO.NET для соотвтствующей СУБД реализовать поддержку параллельных транзакций?
Dimitry SibiryakovArray DML, Array data type, database events notification и т.д. и т.п.
В этом месте смеяться или плакать?
Беру СУБД Oracle , в котором есть и "array DML", и "array data type" - в нем даже пользовательские объектные типы данных имеются... И конечно же в нем есть "database events notification"... Не говоря уже о том, что Oracle изначально версионник, в отличие от большинства существующих версий-блокировочников MSSQL...
Что самое парадоксальное: я беру самый обычный ODP.NET (Oracle Data Provider for .NET) и пользую всю эту туеву хучу фич в самом обычном приложении написаном на C# - и естественно с использованием ADO.NET... Что я делаю не так?

Dimitry Sibiryakovsphinx_mvЧто я делаю не так?
Используешь интерфейсы непосредственно ODP, а не ADO. Т.е. - специализированное API для
конкретной СУБД.
Б.С.К.
Об архитектуре ADO.NET у Вас весьма слабые (до полного отсутствия включительно) представления.
Вы бы по матчасти что-нибудь почитали, что ли - ну, хотя бы в плане архитектуры ADO.NET...

Заодно, глядишь, и осознаете место, которое занимают в ней датапровайдеры конкретных СУБД, и какие интерфейсы эти датапровайдеры обязаны реализовывать.

Dimitry Sibiryakovsphinx_mvосознаете место, которое занимают в ней датапровайдеры конкретных СУБД, и
какие интерфейсы эти датапровайдеры обязаны реализовывать.
ArrayBindCount какие провайдеры реализовывают?
Сферический ArrayBindCount в жидком вакууме? ХЕЗ.

А для Oracle (в ODP.NET) он реализован непосредственно в классе Oracle.DataAccess.Client.OracleCommand - "прямом" потомке класса System.Data.Common.DbCommand.

"Намекаю" еще раз: разработчики, использующие "левосторонние" провайдеры ADO.NET, которые жалуются на отсутствие каких-то фич, пользу от использования которых они даже не способны описать - это проблема ни платформы dotNET, ни ADO.NET, ни тем более Microsoft.
Платформа гарантирует , что библиотеки, реализующие стандартные интерфейсы будут правильно работать на этой платформе. Каждый конкретный вендор должен самостоятельно озаботиться возможностью использования какого-то "исключительно бесполезного функционала" его СУБД. И при реальной заинтересованности не ноют, а реализуют.

kdvsphinx_mv И при реальной заинтересованности не ноют, а реализуют.
это понятно, что в .Net можно написать например Services API Firebird и использовать его, вы тут аналогичный пример про Оракл привели.Чтобы быть ADO.NET-провайдером, в Вашем модуле "Services API Firebird" необходимо и достаточно реализовать стандартные инерфейсы ADO.NET. Расширение функционала этим базовым функциям принципиально не мешает и ограничивается только фантазией и здравым смыслом разработчика.
kdvНо речь об использовании расширенного функционала штатными средствами.
Все с точностью до наоборот: необходимо использовать штатный функционал в расширенной версии - и это требование соблюдается при обязательной реализации базовых интерфейсов ADO.NET.

В среде .NET (и тем более C#) приведение типов наследников (с расширенным функционалом по сравнению с базовым типом) к базовому типу выполняется прозрачно и вряд ли вызовет проблемы даже у программистов, весь опыт разработки которых начинается и заканчивается хэлоуворлдом. Про то, что из наследника непосредственно и полностью доступен весь функционал предка - даже не обсуждается.

И нам известно, что главное требование - любой ADO.NET-провайдер должен наследовать "базовый" функционал ADO.NET. Иначе это не все что угодно, но не ADO.NET-провайдер.
kdvВот, к примеру, нашел TransactionScope
http://stackoverflow.com/questions/224689/transactions-in-net
это вроде как похоже. Но до тех пор, пока этого не было, использовать все это было невозможно.Вы свой зуб поставите на то, что до тех пор пока это не стало "стандартным" это нельзя было реализовать "сторонними" средствами? :)
Обращаю внимание: ArrayBindCount в "базовом" функционале до сих пор все еще отсутствует, но при этом уже очень давно доступен для использования в "правильных" ADO.NET датапровайдерах.

kdvsphinx_mvПараллельные транзакции? В рамках одного коннекта?
Вы уверены? И даже продемонстрировать примерчиком на C# можете?
InterBase/Firebird API поддерживает параллельные транзакции. Соответственно, компоненты типа IBX, FIBPlus, UIB и прочие также реализуют данный функционал.Delphi и CBuilder - не единственные средства разработки приложений для работы с базами данных.
kdv Драйверы типа BDE, ODBC, и скорее всего .Net этого не умеют, потому что у них унифицированная архитектура, расчитанная на совместимость с тучей разных СУБД.ADO.NET датапровайдер для конкретной СУБД может реализовать ЛЮБОЙ функционал, включая даже совершенно не относящийся к функциям взаимодействия с СУБД. Минимальное (но обязательное) требование - "конкретный" ADO.NET датапровайдер должен реализовать "базовый" функционал (см. документацию ).

Напоминаю, что пример как минимум одного датапровайдера (ODP.NET), в котором реализован функционал, отсутствующий в "базовом", приводился. Особых проблем с его использованием не наблюдается.

Dimitry Sibiryakovsphinx_mvADO.NET датапровайдер для конкретной СУБД может реализовать ЛЮБОЙ
функционал, включая даже совершенно не относящийся к функциям взаимодействия с СУБД.
Что в переводе означает "для использования нестандартных фич СУБД придётся использовать
нестандартные интерфейсы конкретного провайдера". КО.
КО на самом деле сказал, что необходимо реализовывать расширения стандартных интерфейсов и пользоваться ими. Но что такое "расширение" Вы себе почему-то представить не можете... Или не хотите...

Если выбраная лично Вами СУБД для лично Ваших проектов настолько "нестандартна", что для ее использования в подавляющем числе случаев (совсем чуть-чуть реже, чем всегда) не хватает весьма обширного набора стандартных интерфейсов, то претензии к Вашему выбору СУБД Вы лично предъявляете как-то совсем не по адресу. Да и Ваши выводы Вы строите не в тему - сугубо на "теории" и в рамках категорической нестандартности выбранной и используемой Вами СУБД.
Dimitry SibiryakovПроще будет сразу использовать API, не имеющее ничего общего с ADO.Это было на правах рекламы сервера БД, для которого невозможно использовать фактические стандарты программных интерфейсов?
Остается только "порадоваться" за Ваш выбор... "Ежики плакали, кололись, но продолжали есть кактус" (с)

Dimitry Sibiryakovsphinx_mvЭто было на правах рекламы сервера БД, для которого невозможно
использовать фактические стандарты программных интерфейсов?
Это было очередное заявление Капитана, которому лень искать баги не только в своём коде,
но и коде многочисленных прокладок между ним и API СУБД.
Капитану как бы уже неоднократно намекалось, что не стоит пользоваться самому (и тем более не рекомендовать этого другим!) отвратительно написанными библиотеками и компонентами с немеряным количеством незакрытых багов в релизной версии. И уж точно не стоило этому капитану делать какие-то далеко идущие выводы на основании своего практически полного невладения предметом и далеко не положительного опыта пользования крайне глючным софтом.

Dimitry Sibiryakovsphinx_mvне стоит пользоваться
Ну так я ими и не пользуюсь. И другим настоятельно не советую.
Нет, ну, это просто праздник какой-то!
И ведь намекалось Вам неоднократно: когда наберетесь хоть какого-то опыта в использовании конктетной технологии, тогда и будете давать советы по ее использованию. А до тех пор из Вас "эксперт" крайне "исключительного" уровня - весь Ваш опыт упирается в использование единственной СУБД, для которой доступен вменяемо реализованый программный интерфейс практически с единственной средой разработки.

С другой стороны, сугубо на основе этих Ваших "супер-советов" легко и непринужденно делается ОЧЕНЬ правильный вывод: как только свяжешься с Interbase/Firebird, проблем огребешь больше, чем пользы. Так что просмотреть Ваш совет, поступить с точностью до наоборот и получить при этом полный комплект плюшек с повидлом - это, в принципе, тоже неплохой вариант.