Использование результатов панели сообщений SQL

У меня есть хранимая процедура SQL 2005, которая по какой-то причине выводит свои результаты на панель Сообщения в SSMS, а не на панель Результаты. (На самом деле это процедура CLR, уже скомпилированная и развернутая на всех наших серверах и используемая для другого ежедневного процесса. Поэтому я не могу ее изменить, я просто хочу использовать ее вывод.)

Ради обсуждения вот хранимый процесс, который ведет себя так же:

CREATE PROCEDURE [dbo].[OutputTest] 
    @Param1  int, @Param2 varchar(100)
AS
BEGIN
    SET NOCOUNT ON;
    PRINT 'C,10000,15000';
    PRINT 'D,30000,90000';
    PRINT 'E,500,50000';
END

Таким образом, здесь нет фактического оператора SELECT, и если вы запустите его, вы увидите эти результаты только на панели сообщений.

Есть ли способ использовать эти результаты как часть более крупного запроса? Поместить их во временную таблицу или что-то в этом роде, чтобы я мог их проанализировать?

Ни один из «обычных вещей» не работает, потому что здесь нет настоящего «вывода»:

INSERT INTO #output
EXEC OutputTest 100, 'bob'

просто показывает

C,10000,15000
D,30000,90000
E,500,50000

(0 row(s) affected)

на панели сообщений, а во временную таблицу на самом деле ничего не помещается.


sql-server ssms sql-server-2005
person BradC    schedule 28.07.2009    source источник

Ответы (5)


arrow_upward
2
arrow_downward

Вы не можете перехватывать, перехватывать или использовать эти сообщения из SQL Server. Однако вы можете получить их из клиентского приложения.

person RBarryYoung    schedule 28.07.2009

arrow_upward
6
arrow_downward

Можете ли вы выполнить хранимую процедуру из кода С#? Если это так, вы можете подключиться к событию SqlCommand с именем SqlInfoMessage:

SqlConnection _con = new SqlConnection("server=.;
            database=Northwind;integrated Security=SSPI;");

_con.InfoMessage += new SqlInfoMessageEventHandler(_con_InfoMessage);

Обработчик события будет выглядеть так:

static void _con_InfoMessage(object sender, SqlInfoMessageEventArgs e)
{
    string myMsg = e.Message;            
}

«e.Message» — это сообщение, распечатываемое в окне сообщений в SQL Server Mgmt Studio.

Хотя это будет некрасиво и может потребовать какого-то уродливого кода синтаксического анализа, по крайней мере, я надеюсь, что таким образом вы сможете получить эти сообщения!

Марк

person marc_s    schedule 28.07.2009

arrow_upward
1
arrow_downward

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

person Chris Simpson    schedule 28.07.2009
comment
Может быть, это и так, но если это возможно возможно, есть и другие применения этой техники, такие как синтаксический анализ результата SET STATISTICS IO ON, который появляется на панели сообщений, когда вы настраиваете запрос. - person BradC; 28.07.2009
comment
Это интересный момент, но я предполагаю, что синтаксический анализ выполняется клиентским приложением, а не сервером sql. Нельзя ли заполучить процесс CLR, исправить проблему и выпустить на сервер вторую версию, чтобы не затрагивать существующих потребителей этого процесса? - person Chris Simpson; 28.07.2009
comment
Мне придется это сделать, если в конечном итоге это окажется невозможным. Хотя я подумал, что сначала посмотрю, смогу ли я использовать существующий процесс. - person BradC; 28.07.2009

arrow_upward
1
arrow_downward

нет способа получить сообщения из панели сообщений в вашем результате. если вы думаете об этом, SSMS — это просто клиент, который анализирует эти сообщения так, как вы их видите.

если вы хотите использовать их в своем приложении, взгляните на События подключения в ADO. НЕТТО

person Mladen Prajdic    schedule 28.07.2009

arrow_upward
1
arrow_downward

Я мог подумать, что это возможно только в том случае, если вывод будет напечатан с помощью команды RAISERROR. В этом случае вы можете захватить его в другом месте, используя TRY/CATCH.

Но это всего лишь идея: я никогда этого не делал. На самом деле, единственное, что мы делаем, что удаленно близко, - это то, что у нас есть инструмент командной строки для запуска хранимых процедур в пакетных заданиях, а не с помощью агента сервера sql для их планирования. Таким образом, все наши ночные задания планируются в одном месте (планировщик задач Windows), а не в двух, а инструмент командной строки фиксирует все, что напечатано в окне сообщения, в общую систему регистрации, которую мы отслеживаем. Таким образом, некоторые процедуры будут выводить в это окно довольно много деталей.

person Joel Coehoorn    schedule 28.07.2009
comment
Это похоже на то, как работает существующий процесс. У нас есть внешний сценарий, который запускает этот процесс на каждом сервере и фиксирует выходные данные сообщения в текстовом файле, а затем обрабатывает и использует этот текстовый файл. Но если мне все равно придется использовать сценарии оболочки, я, вероятно, просто соберу информацию напрямую, а не вызову процедуры (существующая процедура сообщает некоторую статистику дискового пространства, которую T-SQL не может вызвать напрямую) - person BradC; 28.07.2009