2009-03-03 1 views
10

Penso di avere lo stesso problema descritto da kcrumley nella domanda "Problem calling stored procedure from another stored procedure via classic ASP". Tuttavia la sua domanda in realtà non includere una soluzione, così ho deciso di dargli un altro colpo, aggiungendo le mie osservazioni:MS SQL: sopprimere il valore di ritorno della stored procedure richiamata nella procedura memorizzata

Ho due stored procedure:

CREATE PROCEDURE return_1 AS BEGIN 
    SET NOCOUNT ON; 
    SELECT 1 
END 

CREATE PROCEDURE call_return_1_and_return_2 AS BEGIN 
    SET NOCOUNT ON; 
    EXEC return_1 
    SELECT 2 
END 

Si noti che entrambe le procedure contengono "SET NOCOUNT ON ". Quando eseguo "call_return_1_and_return_2" ottengo ancora due record. Innanzitutto il valore 1, quindi il valore 2.

Che genera ASP (classico VBScript ASP) fuori dalle tracce.

Eventuali suggerimenti su come eliminare il primo set di risultati? Perché è lì anche con NOCOUNT?

Saltare il primo set di record in ASP non è un'opzione. Ho bisogno di una soluzione "solo per database".

+0

Un paio di risposte vengono sottolineando che si può passare da un SELECT per un ritorno, ma questa è una grande domanda - cosa succede se la stored nidificato deve selezionare, perché qualcosa di diverso lo chiama, e non puoi cambiarlo? Mi chiedo se sia possibile "inghiottire" un set di risultati del genere. –

risposta

8

Non è il NOCOUNT che causa questo, le procedure memorizzate hanno una selezione ciascuna in modo che ognuna entri nel proprio set di risultati. Ciò potrebbe essere evitato modificando la prima procedura memorizzata in modo da utilizzare i parametri di output per passare il numero 1 indietro anziché effettuare una selezione. La seconda stored procedure potrebbe quindi esaminare il parametro di output per ottenere i dati necessari per l'esecuzione.

provare qualcosa di simile

CREATE PROCEDURE Proc1 
(
    @RetVal INT OUTPUT 
) 
AS 
SET NOCOUNT ON 
SET @RetVal = 1 


CREATE PROCEDURE Proc2 
AS 
SET NOCOUNT ON 
DECLARE @RetVal int 
EXEC [dbo].[Proc1] 
     @RetVal = @RetVal OUTPUT 
SELECT @RetVal as N'@RetVal' 
2

quelli non sono tornare variabili, ma record di uscita. Immagino che non appena il server SQL svuota l'output sul client, sei fregato e non puoi riprenderlo.

Risolverei questo aggiungendo un parametro a SP return_1, che controllerebbe se return_1 selezionasse i record o semplicemente eseguisse e uscisse silenziosamente.

12

Come Matt sottolinea nel suo commento, nessuna delle due soluzioni "inghiotte" il primo set di risultati. Non so perché vorresti questo, ma puoi "inghiottire" il risultato del primo exec usando una variabile di tabella. Deve corrispondere alla quantità e al tipo esatti delle colonne del set di risultati. In questo modo:

CREATE PROCEDURE return_1 AS 
    SET NOCOUNT ON; 
    SELECT 1 
GO 
CREATE PROCEDURE call_return_1_and_return_2 AS 
    SET NOCOUNT ON; 
    DECLARE @Result TABLE (res int) 
    insert into @Result EXEC return_1 
    SELECT 2 
GO