> А если имеется 20-30 типовых запросов, имеющих как общие условия в частях SELECT, WHERE
> и GROUP так и разные, которые зависят от входных параметров (поэтому и используется
> переменная для формирования запроса), то что тогда писать отдельную процедуру на каждый
> запрос ?
Если вы используете технологи ADO, то в ней специально для решения данной задачи имеются средства - параметризованные prepared-запросы. Повторяю, через ODBC эта фича недоступна - только через ADO. В свойствах ADO-компонента присваивается prepared=true, задается текст запроса, в который вместо значений параметров (переменной части запроса) подставляются либо имена параметров, предваряемые двоеточием (в Delphi), либо знаки вопроса (в VBA). Дополнительно создается коллекция ADO-параметров, которая цепляется к данному ADO-компоненту, в которых и указываются значения параметров.
При выполнении такого запроса он компилируется на сервере только первый раз. При компиляции SQL-сервер "знает" о переменных и постоянных частях запроса, то есть план запроса составляется так, как при компиляции хранимых процедур с параметрами. Данный план некоторое время хранится в кэше даже если пославший запрос юзер разорвал соединение. Если от этого же или даже от другого юзера придет аналогичный запрос с другими значениями параметров, то повторная компиляция не производится - подставляются новые значения параметров в ранее сгенеренный план, и запрос выполняется.
В чем отличие SP от параметризованных запросов?
1. Если долгое время не посылать повторно такой запрос на сервер, то план запроса будет вытеснен из кэша и утерян. Это вызовет повторную компиляцию запроса при его повторном получении сервером.
2. Хранимые процедуры возвращают необновляемый набор данных. Параметризованный запрос может возвращать обновляемый набор данных.

2Dmitry: Согласен. Если запрос вызывается 2-3 раза и выполняется 20-30 минут при каждом вызове, время составления плана запроса мало имеет значения. Однако, на практике могут встречаться задачи выполнения в цикле одного и того же параметризованного запроса (с малым временем выполнения) в новым значением параметров на каждом шаге цикла. Если число циклов 1000 и более, а время выполнения запроса мало, то время его компиляции и составления плана оказывается весьма существенным.
2Павел: А тебе известен способ вставки записей в возвращаемый хранимой процедурой набор данных? Что-нибудь вроде Isert into exec MyProc... или Insert into MyProc...?
2Glory: Насчет SQLPrepare. Припоминаю - что-то такое в ODBC действительно было. Приношу извинения за недостоверную информацию. Я мало работал через ODBC, все больше через ADO.

Кстати, я читал в какой-то статье (по-моему на сайте MS) о том, как работает оптимизатор SQL-сервера. Он учитывает такую вешь, как стоимость оптимизации, и производит ее поэтапно. Сначала делается черновая грубая оценка времени выполнения запроса. Если оно получается малым, то дальнейшая оптимизация не выполняется, поскольку затраты времени на оптимизацию могут оказаться выше затрат времени на выполнение запроса с грубо построенным планов выполнения. Если же предварительные результаты оценки показывают, что время выполнения запроса должно быть достаточно большим, производится его более тщательная оптимизация для уменьшения этого времени. IMHO, довольно грамотный поход.

2Павел. В A2K действительно у формы имеется свойство "уникальная таблица", которая позволяет "обмануть" необновляемость набора данных. На самом деле это просто прием, который используется исполняющей системой на самом клиенте - вместо работы с источником данных, который вернул запрос, A2K производит операции вставки/изменения/удаления с уникальной таблицей, которая специально указана как базовый источник данных. В общем случае уникальная таблица может вообще никакого отношения не иметь к данным, возвращенным в запросе ( это я к тому, что следует различать действительно обновляемый набор данных и всякого рода обманки, выполняемые на клиенте). Если параметризованный запрос выполнить через ADO, при условии что аналогичный НЕпараметризованный запрос также возвращает обновляемый набор данных, на клиенте появляется Bookmarkable recordset (терминология OLEDB), который и является условием обновляемости набора данных. Если, к примеру, в Delphi такой набор данных просвечен через DBGrid, то ты можешь непосредственно в нем модифицировать данные, не прибегая ко всякого рода обманкам. Модификация приводит к обращению на SQL-сервер напрямую к нужной записи через механизм Bookmark (меток записи).
2 Dmitry. Лови ссылочку на статьи (там много интересных, включая ту, о которой я говорил) http://www.microsoft.com/rus/sql/rusdocs.html.

2 Павел. Возможно, ты в чем-то прав, и я не совсем корректно попросил привести текст на T-SQL, доказывающий обновляемость набора данных. Однако, в OLEDB такое понятие существует. Известно, что хранимые процедуры возвращают необновляемый набор данных. Если открыть в ADO набор данных, возвращенный SP, то он В СВОЙСТВАХ ADO.Recordset покажет, что набор необновляемый. Ежели выдать команду select ..... чего-нибудь откуды-нибудь, то можно получить набор данных как обновляемый, так и не обновляемый. Вариант указания уникальной таблицы относится к конкретному инструментарию (Access-2000), и более нигде не катит. В Delphi также есть компоненты, выполняющие аналогичные обманные телодвижения. Кстати, в отличие от A2K, в них можно даже сделать так, что вставка будет идти в одну таблицу, модификация будет выполняться над второй, а удаление - в третей. Трудно себе представить, кому такое может понадобиться, но все это сказано лишь с целью подчеркнуть ориентированность определенных приемов на определенный инструментарий. Я же отвечал вообще - без привязки к конкретному инструментарию, а только к механизмам ADO, которые ведут себя схоже в любом инструментарии.
Когда ты в EM открываешь таблицу и модифицируешь в ней строку, то на сервер приходит команда не Update... (которую в аналогичной ситуации формирует A2K), а "exec sp_executesql N'UPDATE......". И еще несколько строк. Подобные строки может формировать ODBC-драйвер, само приложение, а может формировать OLEDB-провайдер, который в общем случае от используемого на клиенте инструментария независим. Вот я о чем.

Я пересказал то, что вычитал (насколько помню, у Дженнингса). Видимо одного свойства Bookmarkable=True недостаточно для того, чтобы получить обновляемый набор данных (однако, если Bookmarkable=false, то набор данных однозначно необновляемый). Видимо, я не совсем правиИнтересно, а что выдаст Debug.Print rst.Supports(adAddNew)? Полагаю, что в первом случае True, а во втором False.

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