Stored pocedure

[Robert_G]

Im Normalfall will man mit dem Wert arbeiten, wird nix gefunden, kannst du das Ergebnis gegen NULL prüfen.
Außerdem war Raiks Code genausowenig für den Produktiveinsatz gedacht, wie es meiner war. ;)

[Hansa]

Zitat:

Zitat von Robert_G

Außerdem war Raiks Code genausowenig für den Produktiveinsatz gedacht, wie es meiner war. ;)

Nein, Raiks Code war schon dafür gedacht. Hast Du das nicht gemerkt ? :mrgreen: Warum sollte er sonst so eine Frage stellen ? Bei Datenbanken geht es immer um was wichtiges/kommerzielles.

Ich habe ihm gesagt, er solle einen Trigger verwenden, der geht aber bei mir seltsamerweise auch nicht richtig.

[BEGINN OT]
Du setzt doch Ora wohl nicht im Kindergarten ein, oder ?
[ENDE OT] :P

[Robert_G]

Ich dachte es sei mehr eine generelle Frage gewesen. :roll:

[Hansa]

was kiar vor hat ist folgendes : zu jedem Datensatz soll das Datum des erstmaligen Erstellens festgehalten werden und das Datum, wenn irgendeiner was ändert. Noch besser wäre es, so habe ich vorgeschlagen, auch noch die ändernde/anlegende Workstation mit zu speichern (für jeden Datensatz).

Das ist wohl schon (meiner Meinung nach) in einem BI/BU Trigger aufgehoben. Kiar meint aber eine Stored Procedure sei dafür besser.

[Robert_G]

Das klingt für mich nach Qualitätssicherung und ISO 9001 :arrow: Audit trial.

Jede Tabelle bekommt ein Feld EditUser und EditDateTime, die werden BU/BI gesetzt.

Billige Lösung:
Ein BU / BD Trigger, der eine Kopie des Datensatzes vor der Änderung in den Audit trial schreibt (bei der billigen Lösung wäre es eine Tabelle mit gleicher Struktur)
In der "richtigen" Tabelle steht also der aktuelle Datensatz mit dem User, der ihn geändert/erzeugt hat, im Audit trial stehen alle Änderungen davor.

Die aufwendigere Lösung wäre EIN Audit für alle Tabellen (, die ein Audit brauchen) pro Tabelle / Feld.
Das wäre dann eine Tabelle, in der der Tabellenname (hier kann auch ein FK zur TabellenID in deinem Data Dictonary, falls vorhanden ;), rein), PK, FeldName (kann ebenfalls auf eine DataDict-Tabelle zeigen), alter Wert, vorheriger EditUser und EditDateTime hinterlegt werden.
Wenn du die Tabelle nach Tabellenname partitionierst dürften die Abfragen darauf nicht langsam werden (die wird ewig lang werden!)

[kiar]

hallo robert,

genau auf deine letzte lösung sollte es herauslaufen.
schön wie du das dargestellt hast :thuimb:

raik

[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 :wink:) , der die noch nicht committeten Operationen speichert.

Wie der aber ausgewertet werden kann, weiß niemand. :mrgreen:

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. :gruebel: 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" :lol:

[CenBells]

Hallo,

Zitat:

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:

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 :wink:) , der die noch nicht committeten Operationen speichert.

Wie der aber ausgewertet werden kann, weiß niemand. :mrgreen:

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. :gruebel: 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" :lol:

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

[kiar]

hallo ken,

hansa und ich philosophieren an dem gleichen thema,

ich bin mit IB 6.0 und hansa mit FB 1.0 an die sache gegangen.
im endeffect suchten wir eine allgemeingültige Variante. ich muss wohl auf FB 1.5 oder das thema knicken.

raik

[Robert_G]

@CenBells
Dein Vorschlag wäre im endeffekt das, was ich als "billige Lösung" vorgeschlagen habe, nur das die Felder

SQL-Code:

Created_date Timestamp Not Null,
Created_By Integer Not Null, -- oder auch String

sinnlos sind.
In der aktiven Tabelle steht der User & das Datum der letzten Änderung, im Audit wäre der Eintrag mit der kleinsten Audit ID zu dieser PK der Eintrag mit dem "Erzeuger". Dabei fällt mir auf: Auch das Audit bräuchte natürlich einen PK.