Използване на резултата от панела 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

Можете ли да изпълните съхранената процедура от C# код? Ако е така, може да сте в състояние да се свържете със събитието 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 proc, да коригирате проблема и да пуснете втора версия на сървъра, така че да не засегнете съществуващите потребители на тази proc? - person Chris Simpson; 28.07.2009
comment
Ще трябва да го направя, ако това в крайна сметка се окаже невъзможно. Мислех си, че може първо да видя дали мога да използвам съществуващата процедура. - person BradC; 28.07.2009

arrow_upward
1
arrow_downward

няма начин да получите съобщения от прозореца за съобщения във вашия резултат. ако се замислите, SSMS е просто клиент, който анализира тези съобщения по начина, по който вие го виждате.

ако искате да ги използвате в приложението си, погледнете Събития за свързване в ADO. NET

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
Това е подобно на начина, по който работи съществуващият процес. Имаме външен скрипт, който изпълнява тази процедура на всеки сървър и улавя изхода на съобщението в текстов файл, след което преминава през и използва този текстов файл. Но ако така или иначе ще трябва да използвам shell скриптове, вероятно просто ще събера информацията директно, вместо да извикам proc (съществуващата proc отчита някои статистики за дисковото пространство, които T-SQL не може да извика директно) - person BradC; 28.07.2009