Błędy: „Nie można zagnieżdżać instrukcji INSERT EXEC”. i „Nie można użyć instrukcji ROLLBACK w instrukcji INSERT-EXEC”. Jak to rozwiązać?

Mam trzy procedury przechowywane Sp1, Sp2i Sp3.

Pierwsza ( Sp1) wykona drugą ( Sp2) i zapisze zwrócone dane do, @tempTB1a druga wykona trzecią ( Sp3) i zapisze dane do @tempTB2.

Jeśli wykonam Sp2to zadziała i zwróci mi wszystkie moje dane z Sp3, ale problem tkwi w Sp1, gdy wykonam to wyświetli ten błąd:

Instrukcja INSERT EXEC nie może być zagnieżdżona

Próbowałem zmienić miejsce execute Sp2i wyświetla mi się kolejny błąd:

Nie można użyć instrukcji ROLLBACK w instrukcji INSERT-EXEC.

Jest to częsty problem podczas próby „bąbelkowania” danych z łańcucha procedur składowanych. Ograniczenie w SQL Server polega na tym, że w danym momencie może być aktywna tylko jedna instrukcja INSERT-EXEC. Polecam zapoznać się z artykułem Jak udostępniać dane między procedurami składowanymi, który jest bardzo dokładnym artykułem na temat wzorców obejścia tego typu problemu.

Na przykład obejściem może być przekształcenie Sp3 w funkcję wartościowaną w tabeli.

To jedyny „prosty” sposób na zrobienie tego w SQL Server bez jakiejś gigantycznej, zawiłej utworzonej funkcji lub wykonanego wywołania ciągu sql, z których oba są okropnymi rozwiązaniami:

1. utwórz tabelę tymczasową
2. openrowset w nim dane procedury składowanej

PRZYKŁAD:

INSERT INTO #YOUR_TEMP_TABLE
SELECT * FROM OPENROWSET ('SQLOLEDB','Server=(local);TRUSTED_CONNECTION=YES;','set fmtonly off EXEC [ServerName].dbo.[StoredProcedureName] 1,2,3')

Uwaga : MUSISZ użyć opcji „set fmtonly off”, ORAZ NIE MOŻESZ dodać do tego dynamicznego sql ani w wywołaniu openrowset, ani dla ciągu zawierającego parametry procedury składowanej, ani dla nazwy tabeli. Dlatego musisz używać tabeli tymczasowej zamiast zmiennych tabeli, co byłoby lepsze, ponieważ w większości przypadków wykonuje ona tabelę tymczasową.

OK, zachęcony przez jimharka, oto przykład starego podejścia z pojedynczą tabelą mieszania: -

CREATE PROCEDURE SP3 as

BEGIN

    SELECT 1, 'Data1'
    UNION ALL
    SELECT 2, 'Data2'

END
go


CREATE PROCEDURE SP2 as

BEGIN

    if exists (select  * from tempdb.dbo.sysobjects o where o.xtype in ('U') and o.id = object_id(N'tempdb..#tmp1'))
        INSERT INTO #tmp1
        EXEC SP3
    else
        EXEC SP3

END
go

CREATE PROCEDURE SP1 as

BEGIN

    EXEC SP2

END
GO


/*
--I want some data back from SP3

-- Just run the SP1

EXEC SP1
*/


/*
--I want some data back from SP3 into a table to do something useful
--Try run this - get an error - can't nest Execs

if exists (select  * from tempdb.dbo.sysobjects o where o.xtype in ('U') and o.id = object_id(N'tempdb..#tmp1'))
    DROP TABLE #tmp1

CREATE TABLE #tmp1 (ID INT, Data VARCHAR(20))

INSERT INTO #tmp1
EXEC SP1


*/

/*
--I want some data back from SP3 into a table to do something useful
--However, if we run this single hash temp table it is in scope anyway so
--no need for the exec insert

if exists (select  * from tempdb.dbo.sysobjects o where o.xtype in ('U') and o.id = object_id(N'tempdb..#tmp1'))
    DROP TABLE #tmp1

CREATE TABLE #tmp1 (ID INT, Data VARCHAR(20))

EXEC SP1

SELECT * FROM #tmp1

*/

Moje obejście tego problemu zawsze polegało na stosowaniu zasady, że pojedyncze tabele tymczasowe z mieszaniem są objęte zakresem wszystkich nazwanych procesów. Więc mam przełącznik opcji w parametrach proc (domyślnie wyłączony). Jeśli ta opcja jest włączona, wywołany proc wstawi wyniki do tabeli tymczasowej utworzonej w procesie wywołującym. Myślę, że w przeszłości poszedłem o krok dalej i umieściłem kod w wywołanym procencie, aby sprawdzić, czy pojedyncza tabela skrótów istnieje w zakresie, jeśli tak, to wstaw kod, w przeciwnym razie zwróć zestaw wyników. Wydaje się, że działa dobrze - najlepszy sposób na przekazywanie dużych zestawów danych między procesami.

Ta sztuczka mi pasuje.

Nie masz tego problemu na serwerze zdalnym, ponieważ na serwerze zdalnym ostatnie polecenie wstawiania czeka na wykonanie poprzedniego polecenia. Nie dotyczy to tego samego serwera.

Skorzystaj z tej sytuacji, aby obejść ten problem.

Jeśli masz uprawnienia do tworzenia serwera połączonego, zrób to. Utwórz ten sam serwer, co serwer połączony.

• w SSMS zaloguj się do swojego serwera
• przejdź do „Server Object
• Kliknij prawym przyciskiem myszy „Połączone serwery”, a następnie „Nowy połączony serwer”
• w oknie dialogowym podaj dowolną nazwę połączonego serwera: np .: THISSERVER
• typ serwera to „Inne źródło danych”
• Dostawca: Dostawca Microsoft OLE DB dla serwera SQL
• Źródło danych: Twój adres IP, może to być również kropka (.), Ponieważ jest to localhost
• Przejdź do zakładki „Bezpieczeństwo” i wybierz trzecią opcję „Wykonaj przy użyciu bieżącego kontekstu zabezpieczeń logowania”
• Jeśli chcesz, możesz edytować opcje serwera (trzecia zakładka)
• Naciśnij OK, twój serwer połączony został utworzony

teraz twoje polecenie Sql w dodatku SP1 to

insert into @myTempTable
exec THISSERVER.MY_DATABASE_NAME.MY_SCHEMA.SP2

Uwierz mi, to działa nawet jeśli masz dynamiczną wstawkę w SP2

Znalazłem rozwiązanie polegające na przekształceniu jednego z produktów w funkcję wartościowaną w tabeli. Zdaję sobie sprawę, że nie zawsze jest to możliwe i wprowadza własne ograniczenia. Jednak zawsze przynajmniej jedna z procedur była do tego dobrym kandydatem. Podoba mi się to rozwiązanie, ponieważ nie wprowadza żadnych „hacków” do rozwiązania.

Napotkałem ten problem podczas próby zaimportowania wyników Stored Proc do tabeli tymczasowej, a ten Stored Proc został wstawiony do tabeli tymczasowej jako część własnej operacji. Problem polega na tym, że SQL Server nie pozwala temu samemu procesowi na zapis do dwóch różnych tabel tymczasowych w tym samym czasie.

Zaakceptowana odpowiedź OPENROWSET działa dobrze, ale musiałem uniknąć używania w moim procesie dowolnego Dynamic SQL lub zewnętrznego dostawcy OLE, więc poszedłem inną drogą.

Jednym z łatwych obejść, które znalazłem, była zmiana tabeli tymczasowej w mojej procedurze składowanej na zmienną tabeli. Działa dokładnie tak samo, jak w przypadku tabeli tymczasowej, ale nie powoduje już konfliktu z inną wstawką do tabeli tymczasowej.

Żeby zapomnieć o komentarzu, wiem, że kilku z was ma zamiar napisać, ostrzegając mnie przed zmiennymi tabeli jako zabójcami wydajności ... Mogę wam tylko powiedzieć, że w 2020 roku opłaca się nie bać się zmiennych tabeli. Gdyby to był rok 2008, a moja baza danych była hostowana na serwerze z 16 GB pamięci RAM i dyskami twardymi 5400 obr./min, mógłbym się z tobą zgodzić. Ale jest rok 2020 i mam macierz SSD jako moją podstawową pamięć masową i setki gigabajtów pamięci RAM. Mógłbym załadować całą bazę danych mojej firmy do zmiennej tabeli i nadal mieć dużo wolnego miejsca w pamięci RAM.

Zmienne tabeli wróciły do ​​menu!

Miałem ten sam problem i niepokój związany z powieleniem kodu w dwóch lub więcej sprocesach. Skończyło się na dodaniu dodatkowego atrybutu dla „trybu”. Pozwoliło to na istnienie wspólnego kodu wewnątrz jednego sproc oraz przepływu skierowanego w trybie i zbioru wyników sproc.

co powiesz na zapisanie wyniku w tabeli statycznej? Lubić

-- SubProcedure: subProcedureName
---------------------------------
-- Save the value
DELETE lastValue_subProcedureName
INSERT INTO lastValue_subProcedureName (Value)
SELECT @Value
-- Return the value
SELECT @Value

-- Procedure
--------------------------------------------
-- get last value of subProcedureName
SELECT Value FROM lastValue_subProcedureName

nie jest to idealne rozwiązanie, ale jest tak proste i nie trzeba wszystkiego przepisywać.

AKTUALIZACJA : poprzednie rozwiązanie nie działa dobrze z równoległymi zapytaniami (asynchroniczne i dostęp dla wielu użytkowników), dlatego teraz używam tabel tymczasowych

-- A local temporary table created in a stored procedure is dropped automatically when the stored procedure is finished. 
-- The table can be referenced by any nested stored procedures executed by the stored procedure that created the table. 
-- The table cannot be referenced by the process that called the stored procedure that created the table.
IF OBJECT_ID('tempdb..#lastValue_spGetData') IS NULL
CREATE TABLE #lastValue_spGetData (Value INT)

-- trigger stored procedure with special silent parameter
EXEC dbo.spGetData 1 --silent mode parameter

spGetDatazawartość zagnieżdżonej procedury składowanej

-- Save the output if temporary table exists.
IF OBJECT_ID('tempdb..#lastValue_spGetData') IS NOT NULL
BEGIN
    DELETE #lastValue_spGetData
    INSERT INTO #lastValue_spGetData(Value)
    SELECT Col1 FROM dbo.Table1
END

 -- stored procedure return
 IF @silentMode = 0
 SELECT Col1 FROM dbo.Table1

Zadeklaruj wyjściową zmienną kursora do wewnętrznego sp:

@c CURSOR VARYING OUTPUT

Następnie zadeklaruj kursor c do zaznaczenia, które chcesz zwrócić. Następnie otwórz kursor. Następnie ustaw odniesienie:

DECLARE c CURSOR LOCAL FAST_FORWARD READ_ONLY FOR 
SELECT ...
OPEN c
SET @c = c 

NIE zamykaj ani nie przydzielaj ponownie.

Teraz wywołaj wewnętrzne sp z zewnętrznego, podając parametr kursora, taki jak:

exec sp_abc a,b,c,, @cOUT OUTPUT

Po wykonaniu wewnętrznego sp, twój @cOUTjest gotowy do pobrania. Zapętl, a następnie zamknij i zwolnij przydział.

Jeśli potrafisz korzystać z innych powiązanych technologii, takich jak C #, sugeruję użycie wbudowanego polecenia SQL z parametrem Transaction.

var sqlCommand = new SqlCommand(commandText, null, transaction);

Stworzyłem prostą aplikację konsolową, która demonstruje tę umiejętność, którą można znaleźć tutaj: https://github.com/hecked12/SQL-Transaction-Using-C-Sharp

Krótko mówiąc, C # pozwala przezwyciężyć to ograniczenie, w którym można sprawdzić dane wyjściowe każdej procedury składowanej i użyć ich w dowolny sposób, na przykład można je przekazać do innej procedury składowanej. Jeśli wynik jest w porządku, możesz zatwierdzić transakcję, w przeciwnym razie możesz cofnąć zmiany za pomocą wycofywania.

W SQL Server 2008 R2 wystąpiła niezgodność w kolumnach tabeli, która spowodowała błąd wycofywania zmian. To zniknęło, kiedy naprawiłem moją zmienną tabeli sqlcmd wypełnioną instrukcją insert-exec, aby pasowała do tej zwróconej przez przechowywany proc. Brakowało kodu_organizacji. W pliku cmd systemu Windows ładuje wynik procedury składowanej i wybiera go.

set SQLTXT= declare @resets as table (org_id nvarchar(9), org_code char(4), ^
tin(char9), old_strt_dt char(10), strt_dt char(10)); ^
insert @resets exec rsp_reset; ^
select * from @resets;

sqlcmd -U user -P pass -d database -S server -Q "%SQLTXT%" -o "OrgReport.txt"