Никогда!! не пользуйтесь методом 2.
Только #1.
Второй вариант вызывает перекомпиляцию пакета " exec my_cool_sp". Вы ведь спокойно могли написать "begin tran
if ... begin ... end commit tran" или чего еще. Цитата из BOL "The prepared statement adds a small precompiled execution plan that calls the stored procedure execution plan, rather than executing the stored procedure execution plan directly."

Во-вторых второй! а не первый вариант приводит к рефрешу параметров только на внутреннем уровне SQL Server. Как часть компиляции пакета.
В-третьих производится двойное приведение типов: сначала на клиенте в строку, затем при разборе пакета обратно в тип параметров.
В-четвертых вы теряете возможность получать out-параметры кроме как в рекордсете. Но рекордсет гораздо более ресурсоемкий объект, чем параметр (см. документацию к OLEDB).

Ну и, наконец, не дай бог, пропустить кавычку или апостроф или столкнуться с разными LCID при составлении скрипта вызова SP.

> П. 3. Это всё та-же компиляция стейтмента!!! Очень быстрая.
Конечно, компиляция стейтмента. Тут все есть компиляция стейтмента.

Тут речь не о скорости выполнения пакета, т.к. ее действительно "нельзя измерить".А об уменьшении трудозатрат. Приходится больше программировать клиентскую часть.

> Использовать нужно не RS("MyField"), а метод GetRows.
Это кому как нравится. Метод GetRows вообще имеет массу недостатков. Копирование рекордсета в массив - на любителя.

> Главное преимущество #2 - меньше потенциальных ошибок, в частности потому, что всю работу с АДО можно вынести в отдельный модуль с 3-мя функциями.
Да - 3 функции это круто. Интересно, а зачем тогда в ADO их гораздо больше? Ведь достаточно только Connection.Execute(), а?
Потенциальных ошибок не меньше - гораздо больше. И именно с приведениями типов при разных LCID клиента и сервера.

>Между прочим, это замедление существенно, оно заметно "на глаз". Сейчас не принято оптимизировать программы, а зря. Время выполнения плохо написанной АСП-страницы может дойти и до десятых долей секунды.

Если замедление вызывает создание пераметров, то АСП не просто полохо, а очень плохо написан. Например, если специально плохо написан.

> Не забывайте, что использование Cmd.Parameters(...) - это обращение к ОЛЕ, поиск метода по имени(!!!), маршаллинг и т.д. - сотни тысяч команд процессора.

Маршаллинг и IDispatch используется в любом случае, если работа идет из ASP. Если же работа идет из C++, то это как напишешь.
Однако вызов SP методами объекта Command приводит к прямому RPC вызову нужной процедуры.
Тогда как вызов SP методами объекта Recordset вызывает процедуру прекомпиляции пакета.

Вообще, у Microsoft сказано:
Don't return a rowset unless you must. ADO constructs a Recordset object whenever the query being executed returns rows. Recordset objects are expensive to construct, so avoid them whenever possible. After it's built, the Recordset provides powerful features, and if you find them useful, you can use a Recordset to pass data back from SQL Server. Keep in mind that it's possible to execute queries that return results but no rows. For example, you can return integer values by using the Return Status parameter. Also, you can return up to 1000 Output parameters (from SQL Server) instead of a rowset, which would require construction of a Recordset.

Я думаю, что дискуссия безсмысленна. Каждый останется при своем мнении.
Раньше я видел, написано было в BOL, что вызов хранимки методом Command является наиболее эффективным, но сейчас найти этой строчки не могу. Однако нигде в литературе вы не найдете строки, подтверждающей эффективность пункта 2.
Везде при вызове SP используется Command de-facto. Иногда Connection (если out-параметров нет).
Я какое-то время назад исследовал проблему вызова SP из ASP страниц. Сидел и с профайлером и груду лит-ры перечитал. Даже перехватывал RPC пакеты. Нашел груду неописанного MS поведения (например, для MS SQL 7.0 невозможно использовать Default-значения для out параметров).

На мой взгляд, методы объекта Recordset нужно вообще использовать как можно реже.
А рекомендаций по использованию разных ADO объектов в MSDN предостаточно.