Интересует можно ли отказаться от этой фичи вообще?
Мне требуется перманентный коннект к Oracle для сохранения в течение всего сеанса значений переменных пакета.

А используется родной Oracle Data Provider или от MS ?

Ну так не закрывать Connection и всё.

> Ну так не закрывать Connection и всё

и еще не использовать датасеты, адаптеры и databinding, в противном случае это будет та же модель, только с незакрытым connection

Я пока не имею понятия что там будет использоваться.
Просто светит миграция win32 приложения на .net. В нем использовался ODAC.
При беглом ознакомлении с Net узнал, что  после того, как вызван fill, все данные летят на клиента и соединение с сервером закрывается.
Вот и хотелось бы узнать, - все на самом деле так ужасно там, или есть возможность нормальной работы с сервером без этого навязчивого сервиса.

> есть возможность нормальной работы с сервером без этого
> навязчивого сервиса.

В целом - есть. На уровне DataReader'а и SQLCommand. Не слишком удобно, но по крайней мере можно

> При беглом ознакомлении с Net узнал, что  после того, как
> вызван fill, все данные летят на клиента и соединение с
> сервером закрывается.

Это дезинформация.
Соединением можно управлять явно.

> DrPass ©   (26.11.05 13:54) [3]
>
> > Ну так не закрывать Connection и всё
>
> и еще не использовать датасеты, адаптеры и databinding,
> в противном случае это будет та же модель, только с незакрытым
> connection

Автору и требуется всего навсего незакрытый коннект.
А Вы путаетесть в терминах: disconnected model не имеет никакого отношения к открытости/закрытости коннекта.

Не вводите людей в заблуждение.

> Вот и хотелось бы узнать, - все на самом деле так ужасно
> там, или есть возможность нормальной работы с сервером без
> этого навязчивого сервиса.

Нет никакого навязчивого сервиса. Есть единственно верный метод работы в клиент-сервер среде.

А если по каким-то техническим причинам нужен постоянный коннект, то и управляйте временем жизни коннекта вручную.

> Автору и требуется всего навсего незакрытый коннект.

Насколько я понял, автору вообще хочется работать с БД традиционным методом, а не с локальным датасетом. Использование которого лишь в частных случаях можно назвать как
> верный метод работы в клиент-сервер среде.

Дело в том, что в существующей системе у меня используются оракловые пакеты. При запуске приложения в этих пакетах инициализируется куча переменных и структур связанных с пользователем.  Все эти переменные и структуры используются в процедурах пакета.
Само собой разумеется, что их значения живут пока живет пользовательская сессия на сервере.
В общем мне нужно что бы сессия жила все время пока запущено клиентское приложение.

OracleConnection conn = new OracleConnection();
conn.ConnectionString = "..."; // посолить по вкусу
conn.Open();

// тут чего угодно, здесь живёт пользовательская сессия.

conn.Close();
// а тут уже не живёт.

В чём проблема -- в упор, извиняюсь, не вижу.

DataAdapter  бережно с соединением обращается, если открыто - пользуется, состояние не меняет, если закрыто- открывает отрабатывает и закрывает после себя

не скажу насчет Oracle, но в MS SQL пул соединений рулит. После закрытия connection, физически он не разрывается, а передается в пул соединений. Disconnect идет на закрытии приложения. Так что можно conn открывать, закрывать в каждом методе, как рекомендует MSDN. Разрыва соединения не произойдет. Вот только незавершенные транзакции откатятся.

Т.е. на

conn.Close();

Коннект не закрывается?
Если это так, то Мелкомягкие опять всех надули.

Profiler говорит что нет

мне это, например, не мешает. Даже удобно

судя по описанию, пулом можно управлять. В т.ч. можно поставить использовать его или нет. В таком случае я думаю что при conn.Close(); соединение будет закрываться

> Т.е. на
>
> conn.Close();
>
> Коннект не закрывается?
> Если это так, то Мелкомягкие опять всех надули.


Почему надули?  Прекрасно все описано в help.
Приложение поддерживает pool соединений. Когда вы вызываете
Close() или Dispose() соединение добавляется в pool, когда вам оно снова понадобится - извлекается.
Именно поэтому рекомендуется открывать/закрывать соединение при доступе к базе, так как если вы забыли где-то это сделать то будет утечка (GC неизвестно когда будет проходить) и получите "The timeout period elapsed prior to obtaining a connection from the pool". Особенно актуально для asp.net.
Нахождение правильного соединения делается по строгому соответствию connection string.
Управление пулом  - опять из той же connection string.
К примеру, data source=server;initial catalog=database;pooling=false; откроет соединение не из пула. Так что если хотите - можете делать ручками.
Можно еще указать размер (min pool size=1;max pool size=50). За подробностями - в msdn

Троелсон в своей книге взахлеб описывал все преимущества работы Disconnect модели.
Оказывается, что реально никакой Disconnect модели нет, т.к. коннект реально сохраняется. Получается, что есть некая виртуальная Disconnect модель, назначение которой весьмо туманно.
Да и вообще, когда узнаешь подобные вещи, то чувствуешь себя кинутым юзером.