_ChaiNikПочитав теорию обнаружил, что ADO.Net предлагает отсоединятся от источника. Может для веба это и хорошо, но по моему скромному представлению в локальных проектах это приводит к задержкам при подключении.[quot]Лучше все таки наверно отключаться каждый раз. Как плюс - не придется писать логику проверки на случай обрыва соединения.
[quot _ChaiNik]Хранить же датасет на клиенте представляется абсурдным из-за его размера. [quot]
А зачем его хранить на клиенте?
[quot _ChaiNik]Я пошел по старому пути, создав одно подключение в основной форме, передавая его в дочерние, т.е. клиент постоянно «висит» подключенным. Насколько это правильно в концепции ADO.Net?[quot] Вопрос не в правильности "концепции ADO.Net", а в правильности концепции твоей программы. Если ты считаешь что нужно постоянное соединение - то пусть оно и будет постоянным.
[quot _ChaiNik]А как быть с пользовательскими контролами использующими данные с сервера?А что с пользовательскими контролами?

Vova_GVPЯ делаю также. Осбенных неудобств не замечаю. И даже сам считаю - так правильнее.
Есть только одно - в один момент может выполняться только одна комманда.
Причем если использовать DataReader и при выполнении произошла ошибка,
то выполнить вторую команду уже нельзя - ошибка Connection Busy или что- то
подобное. Поэтому везде где у меня используется DataReader использую try...catch или finally где делаю
if (DRdr!=null){DRdr.Close();}
Вот про это и речь. Лучше уж открывать соединение каждый раз и закрывать когда оно больше не нужно. А для скорости работы можно разрешить использовать пул соединений.

--
WBR,
Roman S. Golubin
--
Стек легко преобразуется в очередь при помощи автомата Калашникова.

Vova_GVPДа. Еще хочу добавить. Я не передаю Connection в другие формы. Я делаю его static в главной форме и всегда могу к нему обратиться из любой формы как
CMainFm.SqlCnn
Котлеты с мухами мешать не стоит - данные должны быть в одном месте, UI - в другом. Логично предположить, что соединение не имеет ни какого отношения к форме.
Лучше вынести всю работу с соединением с сервером в отдельный класс. Например, Application:

VOVA_GVPНу это уже вкуса, не спорю - можно и отдельным классом Не во вкусе дело. После тебя этот проект другие люди сопровождать будут и им будет не очень понятно, исходя из каких соображений ты запихал соединение в форму. ИМО, обработку данных и UI вообще в отдельные библиотеки разносить надо.
VOVA_GVPНо смысл использования одного Connection на все приложение от этого не меняется :)
Смотри внимательно, что выше написано - каждый раз при вызове статичного Connection создается _НОВОЕ_ соединение. В продолжение примера:

[scr c#]

void DoWork(){
SqlConnection conn = Application.Connection;

// Здесь выполняем действия с соединением

conn.Close();
}

[/src]
Таким образом несколько потоков одновременно могут выполнять свою работу. У каждого - свое собственное соединение, которое, когда оно станет не нужно, поток закрывает сам.

Плюсы:
1. Не надо гадать, оборвано ли, по какой либо причине, соединение или нет. Просто устанавливаем новое соединение и работаем с ним.
2. Не надо ждать, пока соединение перестанут использовать другие потоки.

Минусы:
1. Время затраченное на создание нового соединения. (При помещении соединений в пул оно практически равно нулю).
2. Не забывать закрывать соединения после использования ;-))


--
WBR,
Roman S. Golubin
--
^{Стек легко преобразуется в очередь при помощи автомата Калашникова.}

Alexey KudinovЯ не увидил у автора треда упоминаний о многопоточном приложении или асинхронных операциях. Т.е. можно обойтись и одним экземпляром, просто открывая/закрывая соединение.
Я так же не увидел упоминаний о немногопоточности... просто общий случай. Понятно, что случаи могут быть разные.
Alexey Kudinov
3) желательно всегда точно знать сколько соединений с СУБД у вас открыто в любой произвольно взятый момент времени.
Для чего, если не секрет?
Alexey Kudinov
4) для отладки приложения очень полезно вести лог выполнения SQL запросов. Просто писать в текстовый файл на диске все SQL выражения, которые выполняются приложением. Причем если приложение многопоточное - то для каждого потока/соединения в свой файл.
Вероятно, ты хотел сказать, что для каждого "логического" соединения свой файл, а еще точнее, для каждого сервера. Иначе файлов наплодится... ;-)

--
WBR,
Roman S. Golubin
--
Стек легко преобразуется в очередь при помощи автомата Калашникова.

HummerА ещё лучше делать ремотинг - тогда на клиенте в общем случае кроме фреймворка ничего ставить не надо - особенно, когда приложение одновременно может работать с разными СУБД.
Да, но речь шла о подключении клиентов MSSQL, насколько я понял. И при чем тут ремотинг? Или ты знаешь, как через ремотинг к MSSQL подключаться?

А при подключении клиента к серверу приложения - да, .Net remoting рулит.

2 Hummer:
А я имел в виду сервер приложений, который коннектится к MSSQL ;-))