Интересует можно ли отказаться от этой фичи вообще?
Мне требуется перманентный коннект к 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 модель, назначение которой весьмо туманно.
Да и вообще, когда узнаешь подобные вещи, то чувствуешь себя кинутым юзером.

непонятно откуда такие чувства, вы явно туманно представляете себе работу с отсоединенными данными

> seg   (07.12.05 11:46) [19]

ты уже реально достал ламоразмы свои пейсать.

Если ты читал Троелсона, то какого ляда продолжаешь путаться в терминах?
Или читать -- читал, но ниасилил, потому что буков много?

Не осилил, потому что слишком много хвальбы .NET и поливания грязью всех остальных языков и технологий.
Оказывается, что exe + dll - полный ацтой,
С++ - имеет огромное количество недостатков, которые исправлены в С#.
Java - неповортливая глючная система, и C# просто обязан ее заменить.
Delphi автор уделил пару предложений, что эта среда быстрой разработки, но кому сейчас нужна эта быстрая разработка, сейчас необходимо только качество.
Oracle вообще отсутствует в книге, но подробно расписана работа с Access.

ты почитай любую другую книгу про программирование. Думаешь там они будут подробно описывать другие системы и тем более хвалить их? Ты книгу покупал для описания работы с Оракл? для этого MSDN есть, где это описано.
p.s.
ЕХЕ и длл разве не ацтой? ;) Что ты можешь знать про чужую длл? список экспортируемых функций? а здесь тебе полная инфа. и не надо заморачиваться на разные менеджеры памяти (в случ. delphi)

> seg   (08.12.05 10:53) [22]
> Не осилил, потому что слишком много хвальбы .NET и поливания
> грязью всех остальных языков и технологий.

Это смешно. А если без религиозного фанатизма?


> Оказывается, что exe + dll - полный ацтой,

А были сомнения? Концепция модульности существует с 70-х годов. ехе+длл -- неизбежное зло. Зачем его терпеть?
точНЕТ, конечно, тоже не идеал. Но всё же...


> С++ - имеет огромное количество недостатков, которые исправлены
> в С#.

А были сомнения? Критики Ц++ хватало с момента его появления. Действительно, ублюдский язык. Даже безотносительно к Ц№ и НЕТ.


> Java - неповортливая глючная система, и C# просто обязан
> ее заменить.

Доля правды есть. Надо уметь фильтровать конструктивную критику от маркетоложества. И будет щасье.

Вполне естественно, что в книге по НЕТ будет сравнение в пользу НЕТ.
Есть сомнения, что у НЕТ достаточно положительных сторон? У меня -- нет.
Есть сомнения, что НЕТ не является "серебряной пулей"? У меня -- нет.
Я проблемы не вижу.
То, что реально положительно -- будем к месту использовать. А лапшу -- на дуршлаг.

точНЕТ, конечно, тоже не идеал. Но всё же...

Я давно хочу узнать, какой смысл менять одну неидеальную систему, но уже отлаженную годами, на другую неидеальныю систему, к тому же еще и неотлаженную?

какой смысл тогда вообще штото менять? отчего вы пошли в программисты а не в музейные работники?

"Просто потрепаться вы можете в соответствующей конференции"

извеняюсь

> seg   (08.12.05 12:36) [25]

Тебя никто силком не тянет. Не видишь плюсов -- да пожалуйста! Не пользуйся.
Только не ясно, зачем демагогировать и флеймить...

> Троелсон

Обьявлено о выходе "Pro C# 2005 and the .NET 2.0 Platform" Andrew Troelsen
Между прочем :-) 3-е издание на платформе .NET 2.0 http://www.williamspublishing.com/Books/5-8459-1124-9.html

> alex_*** ©   (06.12.05 12:41) [15]
> Profiler говорит что нет


С этим критерием надо быть поосторожнее, т.к. коннэкшн может тащиться за недобитым объектом. Но в крайнем случае можно вызвать GC насильственно.

В остальном (конструктивном) авторы правы - хочешь юзать непрерывный - юзай. Но использование пула - высшая ступень эволюции.
При "отключенном" коннекте все атрибуты сессии (переменные, временные таблицы и т.п.), кроме транзакций, остаются в силе.