birdyb
Goto Top

SQL Trigger: Komplette Row an Stored Procedure übergeben

Hallo nochmal,

ich habe da nochmal eine Frage zu einem SQL-Problem:
Meine aktuelle Aufgabenstellung ist es, Änderungen in einer Tabelle unseres ERP-Systems zu überwachen (Nur für bestimmte Spalten). Ich habe mir dazu überlegt einen Trigger zu definieren, der nach dem Update greift und die alten mit den neuen Werten vergleicht. Das scheint soweit auch zu funktionieren. Mein Problem ist jedoch, dass ich den Trigger nur im exklusiven Zugriff bearbeiten kann und ich damit für jede Anpassung (die mein Chef dann vielleicht doch noch gerne hätte face-wink ) erstmal alle User rauswerfen muss. Das ist bei einem Rund-um-die-Uhr-Betrieb zwar auch möglich, aber nicht ganz so einfach. Daher nun meine Frage:
Kann ich die Rows, die ich im Trigger per
REFERENCING OLD AS OldRow
    NEW AS NewRow 
anspreche irgendwie an eine Stored Procedure übergeben? Also dass mir die beiden Datensätze in der Stored-Procedure zur Verfügung stehen und ich die Auswertung dann dort vornehmen kann?
Das wäre in sofern sehr hilfreich, als dass ich die Procedure auch so bearbeiten kann und nicht erst den exklusiven Lock benötige.
Oder habt Ihr andere Vorschläge?

Danke schonmal für die Hilfe!

P.S.: Es handelt sich um eine SQL Anywhere 16 Datenbank...

Content-Key: 325346

Url: https://administrator.de/contentid/325346

Printed on: April 26, 2024 at 19:04 o'clock

Member: sabines
sabines Jan 04, 2017 at 06:30:48 (UTC)
Goto Top
Moin,

was spricht dagegen, sowas mit dem Hersteller Support abzusprechen?
So ein schnell geschriebener Trigger oder eine SP kann ungeahnte Folgen haben.

Aus meiner Jugend:
Da hat so eine SP einfach alles einer Tabelle immer wieder komplett in eine UserTable geschrieben und irgendwann war die Datenbank voll (freier MS SQL Server) face-wink

Gruss
Member: BirdyB
BirdyB Jan 04, 2017 at 07:59:26 (UTC)
Goto Top
Moin,
danke für die mahnenden Worte. Im Rahmen des Customizing musste ich jedoch schon genug Tables, Trigger und SPs selbst anlegen. Da kommt der Hersteller ohnehin nicht mehr mit. Ich weiß auch, was ich da tue...
Es geht mir nur um die Frage, ob es für mein Problem eine Lösung gibt, die es mir ermöglicht den Trigger mit den referenzierten Rows in eine SP auszulagern, damit nicht jedesmal das System stillsteht, wenn noch eine Spalte zur Überwachung hinzugefügt oder aus der Überwachung entfernt werden soll.
Ich bin mir nämlich recht sicher, dass da noch die eine oder andere "Könnten wir nicht noch...?"-Frage kommt.
Und ich würde die Anpassung dann gerne vornehmen ohne jedes Mal bis nachts um 3:30 warten zu müssen, bis ich mal kurz alle User und verbundenen Dienste disconnecten darf...

Beste Grüße...
Member: ukulele-7
ukulele-7 Jan 04, 2017 updated at 08:17:04 (UTC)
Goto Top
Also wenn ich dich richtig verstehe willst du nur den Code des Triggers anpassen ohne das die User auf die Anwendung verzichten müssen. Ich hab auf meinem System nicht soviele Zugriffe aber einen Trigger zu droppen und neu zu erstellen läßt sich grundsätzlich in einer Transaktion durchführen und blockiert die Tabelle vielleicht für eine Sekunde wenn überhaupt.

Hier mal mein Code (allerdings MSSQL):
IF EXISTS (	SELECT	1
			FROM	sys.triggers
			WHERE	object_id = OBJECT_ID(N'[dbo].[unt_insert_log]') )  
BEGIN
	DROP TRIGGER [dbo].[unt_insert_log]
END;
GO

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

CREATE TRIGGER	[dbo].[unt_insert_log]
	ON			[dbo].[unt]
	FOR INSERT, UPDATE, DELETE
AS

BEGIN
	SET NOCOUNT ON;

--bla

END;
Ich baue also die Änderungen in den Trigger ein und lösche dann erst den alten um den neuen im Anschluss zu erstellen.
Member: BirdyB
BirdyB Jan 04, 2017 at 08:23:22 (UTC)
Goto Top
Ich versuche das mal in SQL-Anywhere umzusetzen. Das wäre auch eine Lösung. Ich hoffe, das geht dort auch per Transaction.
Member: BirdyB
BirdyB Jan 04, 2017 at 08:58:56 (UTC)
Goto Top
Also du hast mich genau richtig verstanden, nur bekomme ich das in SQL Anywhere einfach nicht hin. Ich habe jetzt mal versucht den Trigger händisch anzulegen. (Also nicht über Sybase Central, sondern direkt per SQL-Konsole). Leider läuft der "CREATE TRIGGER" da ins Leere. Nach einer Minute habe ich das ganze dann abgebrochen...
Hast du da noch eine Idee?
Member: ukulele-7
ukulele-7 Jan 04, 2017 at 09:06:49 (UTC)
Goto Top
Also mit SQL Anywhere habe ich 0 Erfahrung, da müsstest du vielleicht mal den Support (wenn es ihn dort gibt) fragen. Ansich sind Befehle wie DROP und CREATE Trigger ja nichts was man nicht auch während des Betriebs an eine lokale SQL DB übergibt, ich mache das ständig. SQL Anywhere mag hier speziell sein, das wird aber irgendeinem System folgen.
Member: BirdyB
BirdyB Jan 04, 2017 at 09:21:08 (UTC)
Goto Top
Hm, Support ist da eher schwierig, aber ich probiere mal mein Glück... Das Handbuch sagt jedoch:
CREATE TRIGGER setzt eine Tabellensperre für die betreffende Tabelle und erfordert eine exklusive Verwendung der Tabelle.
Und da es noch andere aktive Tabellensperren gibt, sobald andere User angemeldet sind, befürchte ich, dass es bei SQL Anywhere nicht so einfach ist...
Member: ukulele-7
ukulele-7 Jan 04, 2017 at 12:21:16 (UTC)
Goto Top
Nunja die Sperre hält solange an wie der Befehl ausgeführt wird. Das sollte auch mit allen anderen Tablelocks so laufen und die DB kümmert sich um die Reihenfolge.
Member: BirdyB
BirdyB Jan 04, 2017 at 12:24:08 (UTC)
Goto Top
Scheinbar blockt die Anwendung die Table allerdings so dauerhaft, dass mein "Create Trigger" nicht drankommt...