Hallo,
Zitat von
Robert_G:
Rüchkgabewert -> Function, oder ist der
IB Dialekt so verschieden von PL/
SQL?
Ja, Oracle PL/
SQL und
IB SQL sind unterschiedlich
Zitat von
Hansa:
so ungefähr solls wohl sein. Aber das mit dem "Audit Trail" ist zuviel des guten, es geht erstmal darum, daß die Trigger/Procedures sauber laufen.
Da es um
IB/
FB geht, steht zudem ein BDR (Back Difference Record) zur Verfügung (leider sonst nirgends
) , der die noch nicht committeten Operationen speichert.
Wie der aber ausgewertet werden kann, weiß niemand.
Im Moment geht es lediglich darum, das Datum eines Inserts und das des letzten Updates festzuhalten. Am besten natürlich noch ein Delete. Und eben, wer das war.
Für eine Art Logbuch bräuchte man im Prinzip nur eine Extra Tabelle, ungefähr so wie Robert gesagt hat : 4 Felder, Operationstyp (insert, update delete), Operations-Datum, User und irgendeinen zusammengebastelten string, um den DS im nachhinein zu indentifizieren.
Im Moment besteht das Problem allerdings darin, daß bei mir der Trigger nicht richtig läuft und bei kiar die SP auch nicht. 8)
Also : Anforderung ist, das Feld ANGELEGT bei einem INSERT mit dem aktuellen Timestamp zu belegen. Und bei jedem Update
[EDIT] das Feld LETZTEAENDERUNG [ENDE EDIT], wobei vorerst das ältere Datum ruhig überschrieben werden kann unter dem Motto : "der letzte hat gewonnen"
also... *räusper*
Ich habe mit Oracle mal eine sehr schöne Audit-Trail Lösung im Rahmen meines Praktikums implemtiert. Für diesen Fall würde ich aber vorschlagen, in jede relevante Tabelle die folgenden vier felder einzufügen
SQL-Code:
Created_date Timestamp Not Null,
Created_By Integer Not Null, -- oder auch String
Modified_Date TimeStamp Not Null,
Modified_by Integer Not Null
und dann bei jedem entsprechenden Statement die felder created_by und modified_by/Modified_Date (<=CURRENT_TIME verwenden) zu übergeben. So eine Lösung habe ich für jede meiner Tabellen und die Anwender sinds zufrieden.
Dann braucht man nur einen trigger pro tabelle, der das created_date auf die Systime des Servers setzt und gut ist. Keine extra procedure und sonstigen kram und auch keine extra tabelle - Zumindest nicht für ein rudimentäres "Trailing".
Ein Audit Trail benötigt auf jeden Fall eine Extra-Tabelle und da ist es erst mit den generischen Trigger ab
FB 1.5 wirklich schön zu implementieren.
Wenn es noch mit nem Delete sein soll, ist es natürlich die sache.... Aber ohne geht das so ganz gut.
[edit]
Zitat:
uch noch die ändernde/anlegende Workstation mit zu speichern (für jeden Datensatz).
das ist natürlich so ein problem. Du benötigst dazu am besten die connection id und die ist soweit ich weiß erst ab
FB 1.5 verfügbar....
Habe jetzt gerade gelesen, daß kiar einen Audittrail haben will, und da ist es wie gesagt richtig schön erst mit
FB 1.5 aber mit den anderen FBs/IBs natürlich auch kein Problem...
[/edit]
Gruß
Ken