во-первых, хотя это не влияет на выполнение хранимой процедуры, но зачем был использован ODBC, хотя в ADO достаточно OLE DB, которое будет использовано в любом случае.


Почему не работает:
1) в MS SQL при вызове хранимой процедуры в названии процедуры иногда может быть необходимо указать имя её владельца.
2) Фиг его знает, но х.п. можно вызывать по-другому:

Set cn = Server.CreateObject ("ADODB.Connection")

'выбрать тип курсора:
cn.CursorLocation = ... 'adUseServer, adUseClient или adUseNone

'строка соединения:
strConn = "Provider=SQLOLEDB;... итд"

'создать объект команды:
Set cmd = Server.CreateObject ( "ADODB.Command")
cmd.ActiveConnection = cn

'указать, что команда будет вызывать х.п.:
cmd.CommandType = adCmdStoredProc

cmd.CommandText="имя процедуры"
'получаем набор записей результата:
Set rs = cmd.Execute


Здесь используются константы из ADO (напр., adCmdStoredProc = 4)
их можно получить - или импортировать библиотеку типов ADO, или есть включаемый файл с этими константами (кажется, в Platform SDK), или в докуметации по ADO приведена таблица значений.

тут ошибка в строке соединения или нет доступа к базе (проверить по MS SQL Enterprise Manager).
типичная строка для OLE DB (из моей программы):

"Provider=SQLOLEDB;DATABASE=ms8400tif;data Source=PARTISAN\MSSQL0;Initial Catalog=ms8400tif;User Id=Samurai;UID=Samurai;Password="

(посмотреть в документации назначение параметров).

проверить, правильные ли в ней имя, пароль итд.

Для отладки можно с тем же успехом применить соединение через ODBC, это для работы я рекомендовал OLE DB потому что если указать строку соединения ODBC, то ADO обратится к OLE DB, которое обратится к ODBC. Т.е. будет лишний этап при доступе к данным. Правда,может оказаться, что OLE DB расходует больше памяти (при большом наборе записей результата). Это из-за того, что ODBC втоматически создаст серверный курсор для ограничения количества записей, иначе придётся позаботиться самому (следить за расходом памяти).