DB Eintrag nachvollziehen ?

[khh]

Hallo zusammen,
mein Programm bringt es fertig, in Verbindung mit der Eingabe eines Kunden, eine Satz in eine Tabelle anzulegen , der im Primärschlüssel 0 stehen hat.:-(
Ich kann das weder in meiner Entwicklungsumgebung noch bei einer anderen Installation im Programm nachvollziehen.

Gibts datenbankseitig ne Möglichkeit beim nächsten Auftreten des "Phänomens" nachzuvollziehen woher der Eintrag kommt?


Danke Gruss KHH

[mkinzler]

Indem du einen After Post Trigger auf die Tabelle legst und jede Änderung protokollierst

[khh]

Zitat:

Zitat von mkinzler (Beitrag 1031033)

Indem du einen After Post Trigger auf die Tabelle legst und jede Änderung protokollierst

ähm

hast mir da iregendwo nen codeschnipsel ?

danke dir

[mkinzler]

Für was genau?

[khh]

Zitat:

Zitat von mkinzler (Beitrag 1031039)

Für was genau?

was kann ich denn loggen?

datum uhrzeit
was sonst noch?
EDIT: Das Datum schreibe ich normalerweise immer mit.
Was mich dabei stutzig macht, ist, dass in dem Schrottsatz kein Datum geschrieben wird.

am hilfreichsten wäre wenn ich feststellen könnte, ob ein bereits vorhandener Satz überschrieben wird.

Dann hätte ich einen Ansatzpunkt wo ich suchen könnte.

[Hansa]

Er meint wohl einen AFTER UPDATE Trigger.

SQL-Code:

CREATE TRIGGER ADRESSE_AUO FOR ADRESSE
ACTIVE AFTER UPDATE POSITION 0
AS
BEGIN
  UPDATE ADRESSE SET
    LETZTEAENDERUNG = CURRENT_TIMESTAMP
  WHERE (ID = OLD.ID) AND ((LETZTEAENDERUNG IS NULL) OR
        (LETZTEAENDERUNG <> CURRENT_TIMESTAMP));
END
^

Da wird jetzt der Zeitstempel der letzten Änderung eines Datensatzes protokolliert. Müsste man eben für Spezialfälle anpassen. Soll die DB unberührt bleiben, dann könnte man eventuell in Betracht ziehen, ein After Post Ereignis zu nutzen, sofern Zeos das überhaupt kennt. :shock:

[mkinzler]

Wobei das einfügen eines Timestamps einfacher durch einen Defaultwert zu lösen wäre.
In diesem Fall wäre es besser eine Logdatei oder in eine Logtabelle zu schreiben

[Hansa]

@mkinzler : wie, was, Defaultwert ? :shock:

Der Primärschlüssel wird auf 0 gesetzt und das soll nicht so sein, oder ? Es ist ja wohl ein BI-Trigger vorhanden, der die ID/Primärschlüssel anlegt ? Wäre jedenfalls die erste zu untersuchende Stelle. Lege vielleicht besser eine Exception an, die genau dann ausgeführt wird, wenn der Fall der Fälle eben auftritt. Solche dubiosen Fehler sind schwer aufzufinden. Wenn der Enduser allerdings eine Fehlermeldung präsentiert bekommt und direkt anruft und sagt was er vorher gemacht hat, dann kann man das wohl schnell lokalisieren.

[DeddyH]

Es wäre einmal interessant zu sehen, wie der Insert-Trigger aussieht.

[khh]

Zitat:

Zitat von Hansa (Beitrag 1031042)

Er meint wohl einen AFTER UPDATE Trigger.

SQL-Code:

CREATE TRIGGER ADRESSE_AUO FOR ADRESSE
ACTIVE AFTER UPDATE POSITION 0
AS
BEGIN
  UPDATE ADRESSE SET
    LETZTEAENDERUNG = CURRENT_TIMESTAMP
  WHERE (ID = OLD.ID) AND ((LETZTEAENDERUNG IS NULL) OR
        (LETZTEAENDERUNG <> CURRENT_TIMESTAMP));
END
^

Da wird jetzt der Zeitstempel der letzten Änderung eines Datensatzes protokolliert. Müsste man eben für Spezialfälle anpassen. Soll die DB unberührt bleiben, dann könnte man eventuell in Betracht ziehen, ein After Post Ereignis zu nutzen, sofern Zeos das überhaupt kennt. :shock:

ich danke euch, werd ich so installieren.

Gruss KHH

[khh]

Zitat:

Zitat von DeddyH (Beitrag 1031052)

Es wäre einmal interessant zu sehen, wie der Insert-Trigger aussieht.

der Insert Trigger ist ja nicht spektakulär:

SQL-Code:

AS
begin
 IF  (NEW.vkaufkopf_id IS NULL) THEN
     NEW.vkaufkopf_id = GEN_ID(gen_vkaufkopf_id,1);
end

dazu der entsprechende Generator.

Bin auch schon einen Schritt weiter gekommen. Der Fehler entsteht wohl beim Update eines DS.

Da kann ich dann evtl. mal durchsteppen.

[DeddyH]

Die erste Zeile würde ich weglassen. Dazu gab es vor längerer Zeit schon einmal eine Diskussion.

[Sir Rufo]

Für das reine Loggen dieses Fehlers würde ich einen BEFORE-Trigger wählen.

So können auch alle Schreib-Versuche protokolliert werden, auch wenn diese fehlschlagen.

[mkinzler]

Zum Loggen eher AFTER zur Korrektur BEFORE

[Sir Rufo]

Zitat:

Zitat von mkinzler (Beitrag 1031085)

Zum Loggen eher AFTER zur Korrektur BEFORE

Wenn man einen Schreibversuch auch protokollieren möchte, der aber z.B. aufgrund einer Key-Verletzung nicht ausgeführt wird, dann braucht man BEFORE ;)

[Hansa]

Aber ein BI-Trigger nützt wohl kaum was, wenn der Fehler danach gemacht wird. :mrgreen: Ergo : 2 Trigger und dann mal mit F7/F8 durchs Programm wandern.

[DeddyH]

SQL-Code:

AS
begin
-- IF (NEW.vkaufkopf_id IS NULL) THEN
     NEW.vkaufkopf_id = GEN_ID(gen_vkaufkopf_id,1);
end

So kann man die ID angeben oder auch nicht, es wird in jedem Fall der nächste Wert des Generators genommen. Auf diese Weise sollte 0 ausgeschlossen sein.

[khh]

Zitat:

Zitat von DeddyH (Beitrag 1031137)

SQL-Code:

AS
begin
-- IF (NEW.vkaufkopf_id IS NULL) THEN
     NEW.vkaufkopf_id = GEN_ID(gen_vkaufkopf_id,1);
end

So kann man die ID angeben oder auch nicht, es wird in jedem Fall der nächste Wert des Generators genommen. Auf diese Weise sollte 0 ausgeschlossen sein.

ich hatte das so interpretiert, dass der Trigger nur wirkt wenn das Feld "jungfräulich", also NULL ist.
Aber du hast Recht, bei einem neuen Satz ist das immer so, wenn die Erstellung der ID dem Trigger übertragen wird, die Abfrage deshalb überflüssig ;-)

[fkerber]

Hi!

Wenn der Fehler ja durch ein Update auftritt, ist der Insert-Trigger davon ja unberührt (was natürlich nicht den obigen Verbesserungen wiedersprechen soll).

Die Frage ist:
Gibt es irgendwelche Trigger für Update?
Soll beim Update der PK überhaupt verändert werden?


Grüße, Frederic

[idefix2]

SQL-Code:

AS
begin
 IF (NEW.vkaufkopf_id IS NULL) THEN
     NEW.vkaufkopf_id = GEN_ID(gen_vkaufkopf_id,1);
end

NULL ist nicht gleich 0
So wie der Trigger geschrieben ist, wird er nicht aktiviert, wenn Du als Wert 0 in das Feld schreibst, und dann steht nachher eben 0 drinnen. Die Zuweisung im Trigger erfolgt ja nur, wenn id NULL ist.

[DeddyH]

Ich verstehe sowieso nicht, wieso man dem Anwender gestatten sollte, Schlüsselwerte selbst zu vergeben.