Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Serginio1, Вы писали:

_>>>Что-то ты бредишь. Мой оппонент заявлял, что не может использовать Prepare-Execute потому, что плохо держать постоянны подключения (правда почему плохо он так и не объяснил). На что я естественно возразил, что как раз наоборот постоянное подключение эффективнее. И в твоей ссылке именно это и подтверждается. Более того, там указано, что с этим согласны и авторы самого .net, причём настолько, что функции SqlConnection.Open() как раз и берут подключения из некого пула постоянных подключений (а не создают новое каждый раз). Т.е. получается, что в .net как раз по умолчанию используются постоянные подключения. Тогда в чём проблема использовать Prepare-Execute? )
S>> Я так понимаю, что нужно держать не только соединение, но и команду SqlCommand, SqlCommand которая и держит ссылку на план запроса.

_>Правильно понимаешь. )
Ну и держать десятки тысяч SqlCommand держать как то не комильфо. А в нормальных базах таких запросов это обычное дело. Кроме того столь кож еще и динамических
S>>Обычные запросы кэшируются и поиск по строке в словаре выполняется оооочень быстро. Зачем нужны лишние приседания с ручных сохранением запроса, соединения?

_>Ну да, ну да. Создатели СУБД — они просто дураки, что потратили усилия на добавление этой функциональности не посоветовавшись с местными фурумными экспертами. )))
Атавизмы встречаются везде.
S>> Ты на ассемблере еще не программируешь?

_>Бывает изредка, а что? )
Ты хочешь сэкономить миллисекунды на выполнении, и потратить кучу времени на проектирование и программирование и поддержку