-
AUDIT COLUMNS
Moin, moin,
gibt es in SQL eine Möglichkeit über Specialregister oder globale Variablen den Programmnamen zu ermitteln?
Hintergrund: Änderungsvisum in den Dateien/Tabellen sollen von der DB erzeugt werden.
Gruß Andreas
-
Leider nein. Dafür gibt es ein API zur Ermittlung des Callstacks.
Diesen muss man dann nach oben durchhangeln um das erste Programm, dass nicht aus QSYS aufgerufen wurde zu ermitteln.
Allerdings könnte dieses dann auch nur das Filehandler-Programm/Serviceprogramm oder eine exterene SQL-Procedure/Function sein.
Für das API gibt es u.U. auch schon eine SQL-Table-Function.
-
Moin, moin,
danke für die Antwort.
Dann muss eben die SDS wieder herhalten.
-
Zitat von lucullus
Hintergrund: Änderungsvisum in den Dateien/Tabellen sollen von der DB erzeugt werden.
Warum nicht das Audit-Journal?
-
... das Audit Journal ist nicht auf Satzebene. Im normalen Journal ist die Info zwar drin, aber nicht sehr gut auswertbar. Ich würde dennoch über das Journal gehen (wenn ich das wirklich haben will), da dies die gesamte Historie abbildet und nicht nur den letzten Zustand.
D*B
-
Zitat von BenderD
... das Audit Journal ist nicht auf Satzebene. Im normalen Journal ist die Info zwar drin, aber nicht sehr gut auswertbar. Ich würde dennoch über das Journal gehen (wenn ich das wirklich haben will), da dies die gesamte Historie abbildet und nicht nur den letzten Zustand.
Hoppla, ja - ich meinte das Journal. Selbst erzeugte Protokoll-Einträge halte ich immer für sportlich, denn wenn da mal ein Programm was nicht richtig macht, darf man dem Auditor wieder dumme Fragen beantworten
-
"da dies die gesamte Historie abbildet..."?
Wer hebt sich denn tatsächlich die ganzen Journale auf?
Selbst die ganzen neuen SQL-Archivierungsmethoden (Versionierung) ist beim Einsatz von Filehandler-(Service-)Programmen oder sog. App-User-Konzepten vollkommen daneben, da immer der Filehandler also auch der App-User als Verursacher eingetragen wird.
-
... nach meinen Erfahrungen sind Einträge über die letzte Änderung wenig wert, da man den Murks in aller Regel nicht sofort erkennt.
Was die Journale angeht empfehle ich glasklar alle Dateien zu journalisieren und selbstredend die Journale aufzuheben. Gängige Praxis ist hier, drei Tage online zu haben und ältere Journale auf Band vorzuhalten. Will man Daten über die Änderungshistorie der Daten vorhandener Anwendungen einfach verfügbar machen, geht das ohne Änderung der existierenden Anwendung, indem man die Daten periodisch aus dem Journal ausliest und die Historie fortschreibt.
Hat man bereits einen Filehandler, ist man fein raus, dann schreibt eben dieser die gewünschten Historiendaten mit.
D*B
Similar Threads
-
By schatte in forum NEWSboard Programmierung
Antworten: 1
Letzter Beitrag: 22-03-19, 16:52
-
By ILEMax in forum NEWSboard Programmierung
Antworten: 2
Letzter Beitrag: 02-01-18, 15:38
-
By Hrs28 in forum IBM i Hauptforum
Antworten: 0
Letzter Beitrag: 30-03-15, 00:22
-
By harbir in forum NEWSboard IT Strategie
Antworten: 7
Letzter Beitrag: 28-11-12, 12:11
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks