Mam następujący wyzwalacz:

USE SomeDB
GO

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

ALTER TRIGGER [Staging].[RunPivot15] 
ON [Staging].[UriData]
AFTER INSERT, UPDATE 
AS 
BEGIN
    SET NOCOUNT ON
    EXEC [Staging].[PivotData]
END

Nie wystrzeli. Dana tabela otrzymuje około 30 wierszy co pięć minut. Od tego momentu utknąłem. Czytałem to, ponieważ wstawia się więcej niż jeden wiersz, muszę uruchomić kursor. Próbowałem kursora i nie mogę go również uruchomić.

Czy możesz doradzić, jakie jest najlepsze podejście tutaj?

TIA

0
The OrangeGoblin 10 listopad 2018, 15:25

1 odpowiedź

Najlepsza odpowiedź

Jest bardzo mało prawdopodobne, że spust nie zadziała. Dodaj kilka instrukcji print wokół wywołania procedury w wyzwalaczu, ewentualnie również w procedurze składowanej. Pomoże to śledzić wykonanie po uruchomieniu instrukcji aktualizacji w Management Studio w celu uruchomienia wyzwalacza.

USE SomeDB
GO

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO    

ALTER TRIGGER [Staging].[RunPivot15] 
ON [Staging].[UriData]
AFTER INSERT, UPDATE 
AS 
BEGIN
    SET NOCOUNT ON
    PRINT 'Before call.'
    EXEC [Staging].[PivotData]
    PRINT 'After call.'
END

Następnie uruchom instrukcję aktualizacji w Management Studio i sprawdź zakładkę Wiadomości, aby zobaczyć, czy Twoje wiadomości są drukowane.

update Staging.RunPivot15 set SomeColumn = SomeColumn where SomeColumn = SomeValue

Nie, nie potrzebujesz kursorów. Po uruchomieniu wyzwalacza, jeśli dotyczy to więcej niż jednego wiersza, w pseudotablicach wstawionych/usuniętych będzie również wiele wierszy. W twoim przypadku również nie czytasz, które wiersze są aktualizowane, więc po prostu uruchom procedurę. Jeśli chcesz wiedzieć, które wiersze są dokładnie modyfikowane, napisz kod przetwarzający je w podejściu opartym na zbiorach (wszystkie wiersze naraz). Zapętlanie kursorami praktycznie nigdy nie jest dobrym pomysłem w bazie danych.

2
Andrey Nikolov 10 listopad 2018, 16:12