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

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

Я так понимаю, что нужно держать не только соединение, но и команду SqlCommand, SqlCommand которая и держит ссылку на план запроса.
Обычные запросы кэшируются и поиск по строке в словаре выполняется оооочень быстро. Зачем нужны лишние приседания с ручных сохранением запроса, соединения?

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

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

Я так понимаю, что нужно держать не только соединение, но и команду SqlCommand, SqlCommand которая и держит ссылку на план запроса.
Обычные запросы кэшируются и поиск по строке в словаре выполняется оооочень быстро. Зачем нужны лишние приседания с ручных сохранением запроса, соединения?
Ты на ассемблере еще не программируешь?