Datensatz aus PF gelöscht - Wie Protokollieren?

[Andreas_Prouza]

Seit 7.3 gibt's auch das geniale Feature: Temporal Table.
Ist im Prinzip ähnlich wie mit der Trigger Lösung, nur dass es genau für diesen Zweck eine eigene Technik in der DB2 gibt.
Das schöne ist, man kann damit auch die bestehenden Verwaltungsbildschirm-Programme verwenden um den Stand zu einem bestimmten Zeitpunkt sehen zu können.
Beispiel:
Gibt es ein Bildschirmprogramm um Rechnungsinformationen anzeigen zu lassen, braucht man nur vor dem Aufruf von diesem Programm, mit einer SQL Prozedur das gewünschte Datum angeben und dann werden voll automatisch mir am Bildschirm die Rechnungsinformationen vom angegebenen Zeitpunkt angezeigt.
Funktioniert auch mit Native-IO Programme (hab's selbst getestet).
Es müssen die Tabellen nur via ALTER TABLE um ein paar Spalten erweitert werden.
Wenn man diese als Hidden definiert, muss man bei den Programmen nichts weiter machen als sie einfach nur neu kompilieren und fertig.

Die Suche nach dem Ursacher geht dann sehr schnell und einfach. Und für die Anzeige kann man sogar die bestehenden Programme verwenden, was super ist, wenn es sich um Tabellen handeln die in Abhängigkeit stehen und es nicht nur eine einzige ist.
Da kann ich auch soweit zurück in die Vergangenheit wie ich möchte.

[Fuerchau]

Schön, dass die IBM das auch mal implementiert.
Per Definition ist das schon mit ANSI SQL 2011 festgelegt worden.

Aber du glaubst nicht, wie schnell, je nach Tabelle, du da deine Platten vollschreibst.
Es gibt nämlich Anwendungen, die Satzsperren logisch über Feldinhalte durchführen und so am Tag zig1000de Updates durchführen.
Das hatten wir bei Infor ca. 2001 schnell festgestellt, als mal zum Versuch die Journalisierung eingeschaltet wurde;-).

[Andreas_Prouza]

Naja, wenn du im Wiki die ANSI SQL 2011 Beschreibung liest, dann wirst du lesen, dass die IBM DB2 sogar die erste DB war die das implementiert hat.
Oracle erst mit 12c.

Das gleiche Problem mit vollschreiben hast du bei Triggern auch ;-)
Reorg ist in beiden Lösungen das Stichwort.
Dies sollte jedoch bei Bewegungsdaten nur sehr gezielt eingesetzt werden.
Für Stammdaten (so wie hier gefragt) ist es perfekt.

[mk]

Naja, wenn du im Wiki die ANSI SQL 2011 Beschreibung liest, dann wirst du lesen, dass die IBM DB2 sogar die erste DB war die das implementiert hat.
Oracle erst mit 12c.

Das gleiche Problem mit vollschreiben hast du bei Triggern auch ;-)
Reorg ist in beiden Lösungen das Stichwort.
Dies sollte jedoch bei Bewegungsdaten nur sehr gezielt eingesetzt werden.
Für Stammdaten (so wie hier gefragt) ist es perfekt.

Hallo zusammen,

zum Thema Temporal Table

Haben wir auf der IBM i eine Möglichkeit die Anzahl der updates und Inserts einer Tabelle auszuwerten ?
Für Stammdatentabellen wäre es hilfreich vorher zu wissen wieviel Daten sich in einem Zeitraum
ansammeln könnten .
Gruß
Michael

[Andreas_Prouza]

Hallo Michael,

ja das ist einer der Vorteile dabei.
In der History-Table gibt es ein paar zusätzliche Spalten (Aktion, Start- u. Endedatum, Änderungsuser usw.)
Damit kannst du dir eine Liste auswerten lassen, in welchem Zeitraum welche Aktionen (Insert, Delete, Update) von welchen Usern durchgeführt wurden.

lg Andreas

[mk]

Hallo Michael,

ja das ist einer der Vorteile dabei.
In der History-Table gibt es ein paar zusätzliche Spalten (Aktion, Start- u. Endedatum, Änderungsuser usw.)
Damit kannst du dir eine Liste auswerten lassen, in welchem Zeitraum welche Aktionen (Insert, Delete, Update) von welchen Usern durchgeführt wurden.

lg Andreas

Hi Andreas,

sorry da habe ich mich etwas falsch ausgedrückt.

Ich möchte wissen bevor ich eine Tabelle umstelle wie viele Änderungen an einer Table stattfinden

Gruß Michael

[ILEMax]

Ich möchte wissen bevor ich eine Tabelle umstelle wie viele Änderungen an einer Table stattfinden

Ich vermute, das dafür die Künstliche Inteligenz erfunden wurde.
Hieß früher Glaskugel.

Sorry ...

[Andreas_Prouza]

Zusätzlich zur Glaskugel - die meist viel zu sehr Unterschätzt wird :-) - gibt es die Möglichkeit via ACS bei den Tabellen --> Rechts Klick --> Beschreibung --> Aktivität ... die Statistik der Operationen zu einer Tabelle anzusehen.
Du kannst vorher mit Rechts Klick auf die Tabelle dies zurücksetzen lassen um nach z.B. 1 Tag oder Woche zu sehen wie es sich verhält.

[ILEMax]

Zusätzlich zur Glaskugel - die meist viel zu sehr Unterschätzt wird :-) - gibt es die Möglichkeit via ACS bei den Tabellen --> Rechts Klick --> Beschreibung --> Aktivität ... die Statistik der Operationen zu einer Tabelle anzusehen.

Das kann erfahrungsgemäß nur die Vergangenheit anzeigen!

[Andreas_Prouza]

Das kann erfahrungsgemäß nur die Vergangenheit anzeigen!

Außer du kombinierst es mit der Glaskugel

[holgerscherer]

geht auch ein Glasauge?

[Fuerchau]

Problematisch sind aber auf jeden Fall Pseudoänderungen wie sie z.B. bei Infor XPPS angewendet werden.
Dies gilt auch ins besonders bei Stammdaten.
Bei jeder Veränderung von stammdatenbezogenen Werten, wird ein Update auf die Stammdaten mit User/Jobname gemacht, die nach dem Erfolg der Buchung wieder zurückgenommen wird.
Dies ist halt der Nicht-SQL-Methode und dem Nichtwissen von Satzsperrlogiken geschuldet.
Dies war auch das Problem des o.g. Journalversuches, dass ca. 10GB je Stunde an Journaldaten erzeugte.
Bei Temporaltabellen muss man also höllisch aufpassen, dass auch nur tatsächliche Updates stattfinden.
Sonst hast du plötzlich 100te Änderungen 1 Satzes pro Tag.

Wenn man aber Bewegungswerte (Lagerbestand, Auftragsbestand o.ä.) in Stammdaten unterbringt sind Temporaltabellen nicht empfehlenswert. Hier muss man auf jeden Fall genau prüfen bevor man das umsetzt.

Zur Auswertung solcher Änderungen ist hier tatsächlich nur ein Journal möglich, wie es Dieter schon beschrieben hat, da hiier nur auf Satzebene protokolliert wird. Auditjournale beobachten nur Objektveränderungen.