For Each Trigger Debuging-Verbindung

[Chriss]

Hallo,

ich bin recht neu im Datenbanksegment und vor allem in Oracle, und habe gleich mal eine Anfängerfrage.

Ich möchte einen Trigger schreiben, der mir alle neuen Zeilen, die in eine Tabelle geschrieben werden aufbereitet.
Dazu bin ich wie folgt vorgegangen:

AFTER INSERT ON T_NEU 

REFERENCING NEW AS NEW OLD AS OLD

FOR EACH ROW

DECLARE 
...

BEGIN
  dbms_debug_jdwp.connect_tcp('10.10.10.10',4000);

  <Hier wird verarbeitet>

  dbms_debug_jdwp.disconnect();
END;

Da der Trigger nun in der Schleife die Debugverbindung aufbaut macht er das für jeden Datensatz. Also muss ich am Ende der Verarbeitung die Verbindung trennen, damit er sie beim nächsten Satz wieder aufbauen kann. Dies erscheint mir aber nicht sehr elegant. Kann man hier nicht vor der Schleifeanweisung die Verbindung aufbauen und danach wieder beenden?

Für Hilstestellung wäre ich dankbar!

[defo]

Ich kenne das Paket nicht und hab's mir nun auch nicht angeschaut. So wie es klingt, würde ich es aber vermutlich nicht im Trigger aufrufen.

Frage wäre zunächst mal, was Du erreichen möchtest?
Vielleicht tut es ein simples Logging in eine text datei?

Wenn nicht:
Der Trigger ruft nicht selbst das Paket auf, sondern du baust ein Wrapperpaket nach Deinem Bedarf.
Das Paket connected im Init mit dem Debugger und nutzt Session Variablen, um die Connection zu halten, bleibt also permanent connected.
Wahrscheinlich musst Du irgendwie noch auf Session Ende reagieren, um Du die Verbindung sauber abzubauen

[Wernfried]

Du kannst das FOR EACH ROW weglassen, dann wird der Trigger nur einmal pro INSERT Statement ausgeführt. Natürlich werden dann alle Datensätze verarbeitet.

Seit Oracle 11 gibt es die sog. Compound Trigger, dort kann man das Ganze kombinieren:
[highlight=sql]
CREATE OR REPLACE TRIGGER UIC_T_NEU
FOR INSERT ON T_NEU
COMPOUND TRIGGER

BEFORE STATEMENT IS
BEGIN
DBMS_DEBUG_JDWP.CONNECT_TCP('10.10.10.10',4000);
END BEFORE STATEMENT;
AFTER EACH ROW IS
BEGIN
...
<Hier wird verarbeitet>
END AFTER EACH ROW;
AFTER STATEMENT IS
BEGIN
DBMS_DEBUG_JDWP.DISCONNECT();
END AFTER STATEMENT;
END;
[/highlight]


Ich habe jedoch die gleichen Zweifel wie defo: Was genau soll der Trigger machen?
Grundsätzlich dient das Package zum Debuggen, das wird überlicherweise nur beim Entwickeln verwendet aber nicht als permanente Lösung in einer Anwendung.

Der Code in einem Trigger ist grundsätzlich Bestandteil des ausgeführten DML Statements. Wenn nach dem INSERT ein ROLLBACK gemacht wird, wird der Code trotzdem ausgeführt, soll das so sein?

Soweit ich beim Überfliegen das Package DBMS_DEBUG_JDWP verstehe kann man damit PL/SQL packages im Visual Studio .NET debuggen, wie das mit einem DML Statement zusammen hängen soll ist mir nicht klar.

Das zeilenweise Ausführen einer Anwendung wie du es vom Visual Studio her kennst ist bei PL/SQL nur sehr beschränkt möglich.
Meine Empfehlung: Versuche es erst gar nicht, da es vermutlich mehr Probleme verursacht als es dir hilft. Verwende statt dessen DBMS_OUTPUT.PUT_LINE ( '....' ); im Code - aber nur während der Entwicklung!

Gruss

[defo]

falls es um simples loggen geht:
DBMS_OUTPUT benötigt eine Consolenverbindung bzw. eine IDE, die die Ausgaben entgegennimmt und darstellt.
Auch beim Debuggen kenne ich es so, dass es erst am Ende der Prozedur die Rückgabewerte liefert, ist also nicht live (Hierfür muss ggF der Buffer vergrößert werden)

Es gibt io_routinen, die serverseitig in eine Textdatei schreiben, das benutze ich lieber als DBMS_OUTPUT. Hängt aber vlt auch davon ab, wie gut die IDE mit DBMS_OUTPUT kann. Wenn Du ernsthaft mit dem System arbeitest, wirst Du eh eine Log Routine brauchen. Findet man im Netz.

Notfalls könnte man auch in eine andere Tabelle loggen, halte ich aber für 2nd best oder so. Auf dem Weg wirst Du niemals erfahren, wenn der Tablespace vollgelaufen ist.

Falls es um loggen komplexer Vorgänge geht- hier in einem Trigger- würde ich von den komplexen Vorgängen im Trigger abraten.
Dazu gehört im Zweifel bereits soetwas wie "wenn ein Satz eingefügt wird, füge auch direkt einen zugehörigen Detaildatensatz an"
Soetwas besser in einem Paket anlegen, dass einen Workflow / Business rules abfackelt. Also bspw. eine komplexe Insert Operation (über mehrere Tabellen), die kann dann a) unabhängig vom Trigger aufgerufen und getestet werden und b) mit vielen IDE direkt debugged werden.
Im Trigger würde ich nur grundlegende Operationen wie ID Vergabe, Änderungsdatum, usw. regeln.

[Chriss]

Hallo,

Vielen Dank für die Antworten!

Ich benötige das auch nur für die Entwicklung. Im späteren Einsatz wird das nichtmehr benötigt. Was ganz praktisch daran ist, dass man Schrittweise durch den Trigger steppen kann und sieht, was die Variablen beinhalten. So lässt sich sehr praktisch sehen, an welcher Zeile ein Fehler auftritt.
Ich kann das VB-Programm starten und sobald der Trigger aufgerufen wird, kann ich dann im Developer genau sehen, was gemacht wird.

Aber in dem Fall werde ich das so belassen, wie ich es habe. Wie gesagt, ich dachte nur, dass es eventuell eine elegantere/schönere Lösung gibt. Aber es erfüllt ja seinen Zweck!

Vielen Dank!

[defo]

"Im späteren Einsatz..nicht mehr benötigt.."
Ok, also später gibt es keine Fehler mehr?
Vielleicht doch, ganz selten, aber dann kannst Du ja immernoch mit deinem Laptop zum Kunden fahren und debuggen.