Дело в том, что в ado.net существует пул коннектов. При этом два соединения с одинаковой строкой подключения, если они не используются одновременно, используют один и тот же объект, обеспечивающий подключение к серверу.
--
WBR,
RA1OGE

Да. Плюс, ни кто не запрещает создать свой класс, унаследовав его от общего абстрактного класса, содержащего SqlConnection как static member. Пример можете посмотреть тут .

О чем это я? Не SqlConnection, конечно. В Вашем случае OleDbConnection :-)

--
GL RA1OGE

Анатолий ИвановПро пул слышал. Но "если они не используются одновременно" - тогда получается что родительская форма должна закрыть соединение до того, как откроется дочерняя форма.
Ну да, а если она не закрыла, то в пуле создается еще одно точно такое же соединение и используется оно. Именно этим и удобен пул соединений.
Анатолий ИвановВсе таки, я не услышал ответа на вопрос: как добиться в дизайн-тайм использования во всех формах одного и того же соединения и если нельзя то почему?
Вы сами себе противоречите - как Вы будете тогда разделять это соединение между родительской и дочерней формами? Одновременно в одном соединении можно выполнять только одну команду.

Анатолий ИвановЭто опять же рантайм-решение. В этом случае я могу и одно и то же соединение везде передавать.
А что в Вашем понимании "рантайм"? Вся Visual Studio сама по себе рантайм!

Анатолий ИвановНу и попутно теряем содержимое временных таблиц, вернее не видим его, т.к. соединение - другое.
Да ну? Если все заранее обдумать, то ни чего не теряется.
Анатолий ИвановА мне одновременно и не надо. Важно чтобы результаты одной могла увидеть другая (во временных таблицах).
Да увидит она, увидит. При грамотном проектировании каждое соединение используется один раз, "перемещаясь" между формами, потому как оно на формы и не должно быть завязано вовсе.
Анатолий ИвановХорошо, скажем так: зачем самому писать то, что дизайнер и так напишет также?Затем, что "размещать" соединение с сервером на форме подобно выливанию компота в суп перед едой. Можно после этого всем жаловаться на повара и говорить, что он плохо сварил суп и компот, потому что вместе их есть не с руки.

При правильном же проектировании (то что здесь называют "best practice"), система распадается, как мнинмум, на три составляющие, очень слабо связанные друг с другом (обычно даже выделенные в отдельные библиотеки):
1. Так называемый DAL (Data Access Layer), обеспечивающий соединение с сервером и выполнение всех запросов к нему.
2. BLL (Business Logic Layer), обеспечивающий логику работы приложения. Представляет из себя набор классов, пользующихся сервисом, предоставляемым DAL.
3. GUI (User Interface) - интерфейс пользователя занимающийся выводом сообщений, отображением форм, обработкой событий кнопок и мыши и передачи их в BLL.

При таком подходе к проектированию, вопроса "почему нельзя разместить одно соединение на несколько форм" просто не может существовать, так как в 99.9% случаев форма вообще не знает, с каким источником данных работает программа. Так же как и компоненты DAL совершенно не в курсе, в Windows.Forms их выводят или на веб-странице.
Кроме того, один раз грамотно написанный DAL позволит в дальнейшем избежать огромного числа ошибок при программировании, увеличить уровень безопасности приложения и, при средних размерах программы, сократит размер кода на порядок.

Подробнее о таком подходе к проектированию Вы можете почитать в MSDN (на сайте Microsoft) по ключевым словам DAL, BLL, GUI- там все подробно расписано.

Хотел уже спать идти ложиться, но понял еще одну деталь, которая в последствии может Вам, как разработчику, акнуться всвязи с практикой передачи неких данных через временные таблицы на сервере.
Простейшая ситуация: разрыв соединения. Все Ваши временные таблицы сервер успешно похоронит. А в них может оказаться, например, работа оператора в течении нескольких часов.
При описанном же выше подходе Вы просто восстанавливаете соединение и спокойно продолжаете работать. Бизнес логика приложения разрыва соединения даже не заметит, так как управление соединением находится в закрытом от нее DAL.