Пермишенсы на создание временных таблиц никому не требуются, т.к. это есть - внутренние объекты самого сервера и он создает их в специальной временной базе, в которую допускает любой контекст пользователя (тем более, что существуют эти таблицы только на время исполнения запроса, или процедуры, и только в сессии определенного пользователя, поэтому никого не колышут права на их создание/удаление).

Теперь насчет ADO и вызова процедур с временными таблицами: может я и не в ту сторону киваю, но даже на MS SQL 7.0 при открытии рекордсета в ADO путем банального Set recordset = command.Execute( "my_proc @my_param1=0, @my_param2=null" ) наблюдались довольно странные вещи...
А именно:
- если в процедуре не было использования временных таблиц, то recordset нормально открывался и был пустым даже если итоговый запрос в вызываемой процедуре не возвращал НИ ЕДИНОЙ строчки... Просто свойство EOF у этого recordset-а честно было равно True;
- если же в процедуре использовались временные таблицы, то (при определенных условиях) recordset ни за что не хотел открываться (и соотв-но свойства EOF у него НЕ БЫЛО), хотя он заведомо не должен был быть пустым, т.к. вызов той же процедуры с теми же параметрами в QA давал замечательную выборку данных...

Что же это за "определенные условия"?
Как ни странно, это инструкция SET NOCOUNT ON в самом начале любой процедуры, которая использует временные таблицы (вам, наверное, приходилось наблюдать в окне QA очень "информативные" сообщения типа "(n row(s) affected)" на каждое действие с временной таблицей в ходе выполнения процедуры, вот они-то как раз и не нужны никому нафиг при открытии рекордсета, человек-то может "абстрагироваться" от этого мусора при просмотре результатов, а вот ADO не может).

Может, я пишу и банальности, которые всем известны, но мне самому пришлось довольно долго с этим протрахаться, да еще и понаблюдать как с этим трахались пара моих знакомых...

З.Ы. А для проверки открытия recordset-а (ИМХО) лучше сначала использовать свойство State и проверять его на равенство adStateOpen, т.к. EOF действительно существует ТОЛЬКО у открытого recordset-а, пусть даже в нем пусто как в степи зимой... )

Ну, с директивами-то "разбираться" - дело как раз нехитрое... (если вы хоть кое-как читаете по-английски).

Обычно вместе с сервером народ проставляет себе Books Online, где все достаточно подробно написано (жаль, что по-английски). Для более-менее "адекватного" понимания текстов из Books Online (ИМХО) нужно немного иметь представления об "архитектуре" функционирования SQL-серверов вообще (к сожалению, это приходит только с опытом), а в Books Online узнавать только "частности" для конкретной версии MS SQL Server.

Если вы действительно хотите "разобраться" и при этом не напрягать пользователей изменениями в рабочих процедурах - напишите ЛЮБУЮ "тестовую" процедуру лично для себя и ставьте туда ЛЮБЫЕ директивы SET, т.к. их действие ограничено только вашим коннектом и временем исполнения этой процедуры.

Что же касается конкретики:
SET QUOTED_IDENTIFIER OFF - выключает режим распознавания имен объектов, записанных в двойных кавычках (например так: SELECT "my_field" FROM "My_Table" при данной установке не прокатит, хотя по стандарту ANSI допустимо), полезность данной установки в том, что можно строковые переменные заключать в двойные кавычки, если есть необходимость засунуть туда апострофы (например так:
EXEC("select * from my_table where my_text_field like '%BullShit%' and my_flag_field is not null")).
GO
SET ANSI_NULLS ON - включает режим сравнения NULL в стандарте ANSI (SQL-92), т.е. ЛЮБОЕ сравнение значения с NULL будет возвращать False (что "... WHERE my_field<>NULL ...", что "... WHERE my_field=NULL ..." не выберет вам НИ ОДНОЙ СТРОЧКИ независимо от значения поля "my_field", т.е. придется вам использовать более правильную (с точки зрения стандарта ANSI SQL-92) конструкцию "... WHERE my_field is [not] NULL ...", это "дисциплинирует" )
GO
SET NOCOUNT OFF - отключает режим, когда строчки (n row(s) affected) НЕ ОТОБРАЖАЮТСЯ, соотв-но - SET NOCOUNT ON включает этот режим.

Кстати, GO совершенно необязательно писать за каждой директивой, т.к. контекст их использования все равно ограничен телом процедуры...

З.Ы. Спасибо за добрые слова... , а слово "банальный" я использовал только лишь потому, что данный вопрос (об ADO recordset и временных таблицах в процедуре) уже обсуждался на форуме у А. Гладченко, который "прирос" к этому форуму... (надо было просто покопаться в архивах).

О, блин, чуть не забыл предупредить (как раз из серии того, что приходит "с опытом").

Некоторые директивы SET уже являются "предустановленными" для любой базы данных (проверяются системной процедурой "sp_dboption"), и самое подлое в этом деле, что некоторые могут быть изменены в пользовательской процедуре, а некоторые - хрена лысого, т.е. если на всю базу установлено более сильное ограничение (например: SET ANSI_WARNINGS ON), то хоть обвставляйся директивами SET ARITHIGNORE ON/OFF - никакого эффекта не последует...

Но, к счастью, обо всех этих "тонких взаимоотношениях" всегда прописано в Books Online.

Удачи!!

>Я запустил sp_dboption и она, если я правильно понял, выдает список опций, которые можно менять. Так вот NOCOUNT там >отсутствует... Это значит, что она где-то выше прописана?

Нет, немножко не так... (вот он для чего опыт-то нужен, если этого не знаешь, или кто-то не рассказал - то хрен сам и догадаешься).
Все параметры (опции) SET {DIRECTIVE} имеют 2 состояния ("вкл."/"выкл." ON/OFF), соответствующие команды эти опции включают (SET ... ON), или отключают (SET ... OFF), процедура sp_dboption показывает список опций, которые имеют состояние "ON" (т.е. все остальные возможные опции уже установлены в "OFF", как и ваш NOCOUNT, который "отсутствует").

>И еще, я попробовал в начало процедуры прописать SET NOCOUNT... Так после создания процедуры эта строчка пропадает

??!! Вот этого я совсем не понял... , как это - "пропадает"? Т.е. получается, что в тексте процедуры после ее генерации не остается строчки "SET NOCOUNT..."?
Приведите здесь (если не сложно) 5-7 строчек из начала процедуры, чтобы было ясно - как оно написано?

Ну попробуйте вот такую фигнюшку исполнить:

if Exists(SELECT * FROM sysobjects WHERE id=object_id('dbo.my_tmp_proc'))
drop Procedure dbo.my_tmp_proc

GO

create procedure my_tmp_proc
@pDate datetime = null
as
begin
set nocount on
declare @sDate datetime, @iCount int
create table #T (tDate datetime)
if @pDate is null
insert into #T select getdate()
else
insert into #T select @pDate
select @iCount=-1
while @iCount>=-5
begin
select @sDate=min(tDate) from #T
insert into #T select dateadd(month,-1,@SDate)
select @iCount=@iCount-1
end
exec('select * from #T')
return
end

GO

exec my_tmp_proc

GO

sp_helptext my_tmp_proc

А потом скажете мне - что и куда там пропадает?

>А посредством какого програмного продукта ты процедуры создаешь?
>(я пытаюсь выяснить кто это другой, кто стрелял)

Да уж... вопрос, что называется - "не в бровь, а в глаз"...
Я например, видел собственными глазами как в MS SQL 7.0 Enterprise Manager посылал серверу SET-директивы ДИМЕТРАЛЬНО-ПРОТИВОПОЛЖНЫЕ тем, которые посылал Query Analyzer (и все это "в фоне", независимо от желания пользователя)...
(т.е. один и тот же текст на T-SQL вызывал разную реакцию, в зависимости от того - каким приложением пытались создавать процедуру).

Не отчаивайся...
(жаль, у меня рабочий день заканчивается, завтра мне, наверное, уже лень будет опять "обсасывать" эту тему).

Попробуй быть "последовательным"...
Не делай так, как советовал SergSuper: "SET NOCOUNT ON НАДО поставить в начало процедуры, а SET NOCOUNT OFF поставить перед последним селектом, который будет выплевывать данные", (я етого никогда не советовал).

Не нужны для открытия рекордсета НИКАКИЕ "(n row(s) affected)" (ни 1 раз, ни 0 раз - вообще избавься от них).

Т.е. оставь только SET NOCOUNT ON сразу после CREATE PROCEDURE ... AS ...
На установки db_options это НИКАК не повлияет, т.к. "жить" оно будет только во время исполнения этой процедуры.

("Еще 1 рывок, еще 1-на попытка!!")