Protokollierung von Stammdaten

[Fuerchau]

In ILE ist das doch kein Problem:
Die Protokoll-Tabelle ist identisch zur Basistabelle (Namen und Definitionen) nebst Zusatzinfos wie Timestamp usw.
Ggf. kannst du Workfelder der Tabelle, die nichts mit den reinen Stammdaten zu tun haben rauslassen.
Dann kann man leichter auch tatsächliche Änderungen vergleichen und unnötige Protokolleinträge verhindern.

Im Trigger bekommst du ja die beiden Puffer, die du mit qualified based pointer definierst.
Für die Zieltabelle hats du ebenso die DS qualified.
Nun machst du einen "eval-corr ZielDS = FromDS", kopierst also alle Felder, ergänzt den Rest und schwups bist du fertig.

Mit SQL-Trigger ist es leider schwieriger, da du da keine Strukturen hast und jedes Feld einzeln im Insert angeben musst.

[DKSPROFI]

Moin,

danke Dir, aber die FromDS ist das Satzformat, ZielDS ist keine DS, sondern ein Alphafeld. Die Übertragung in sich funzt ja, aber die nummerische gepackten Felder funzen nicht.

mfg

DKSPROFI

[Robi]

Was heist

die nummerische gepackten Felder funzen nicht.

Türlich geht das! sie sind nur nicht mit dsppfm ohne f10 F11 lesbar, da sie gepackt da stehen.
Schiebst du den String zurück in die DS ist alles da!

Wir retten auf diese Art Daten, um diese nach missglückem Test wieder hin zu stellen.
Läuft schon ewig!
Robi

[DKSPROFI]

Moin Robi,

vielen Dank, das isses. Genau das war der denkste. Vielen Dank noch einmal.

mfg

DKSPROFI

[Fuerchau]

Ich würde das aber nicht mit Charfeldern sichern, da ist ja nichts mit SQL möglich.
Und was machst du mal bei Dateiänderungen?
CHGPF mit Source erhält ja die Daten und fügt neue Felder hinzu. Das gilt auch für "Create or Replace Table".
Zusätzlich lässt sich die Protokolldatei auch mit SQL auswerten.
Diesen Verlust solltest du nicht hinnehmen.

Man kann dann auch schnell mal per SQL einzelne Werte/Zeilen wieder herstellen.

[DKSPROFI]

Moin,

die Chefetage will nicht wieder herstellen, sondern will wissen, wer hat wann und was im Satz geändert.

Also,

Feld 01 wurde geändert am von <Feldinhalt alt> <Feldinhalt neu>
Feld 99 wurde geändert am von <Feldinhalt alt> <Feldinhalt neu>

Dateiänderungen sind da eigentlich nicht das Problem, die aktuelle Struktur und die Feldliste wird ja gezogen über die EDS und das auslesen der Felder erfolgt über QADBIFLD.

Aus diesem Grund wollten wird das über eine DS lösen. Das Auslesen des Datenfeldes ALT/NEU sollte dann idealerweise über eine weiter DS erfolgen, DSFeld(1) = Feldinhalt, DSFeld(99) = Feldinhalt, ohne das aus dem Alphafeld die Positionen zu bestimmen, also von 1 bis a, von b- c usw.

Alos wäre es fantatastsich die EDS in eine DS zu bringen die den Feldinhalt aller Felder enthält und diese mit dem Index der Feldposition ansprechen könnte.

mfg

DKSPROFI

[Fuerchau]

Warum so so kompliziert, wenn es mit SQL viel einfacher wäre;-).
Bei gepackten Felder hast du eben das Problem, dass dies nicht einfacher macht.
Allerdings kannst du die gepackten Felder ja in HEX umwandeln (z.B. per SQL).
Dann hast du die Ziffern und rechts das Vorzeichen (F = +, D = -).
Dafür kannst du dir dann auch einen Service (Unterfunktion) bauen.

[DKSPROFI]

Hallo Baldur,

eigentlich ist es gar nicht kompliziert, Satzformat mit Inhalt vorher/nachher in ein Feld und speichern und entsprechend aufbewahren.
Wenn dann gewünscht, Datensatz mit lesen aus dem Feld in DS und anzeigen. Da ist nur das Problem, das der Feldinhalt dann in einer DS steht, die wiederum in einer Subfile Feldweise angezeigt werden soll.

Demnach müssen die Einzeldateifelder der DS angezeigt werden und demnach mit %EDITx und so aufbereitet werden.
Also muss ich leider auch aus der DS die Dateifelder wieder ansprechen.

Also aus einem 4096 langen Feld müssen die Einzelfelder wieder ausgelesen werde. Das funktioniert mit dem Tipp von Robi sehr gut.

Ich hatte mir vorgestellt die DS mit anzusprechen mit DsName(Feldnummer). Das funktioniert aber nicht, da die Felder aufbereitet werden. Mit %Char hätte ich mir das unter Umständern erspart.

mfg

DKSPROFI

[Fuerchau]

Ich sag ja, warum einfach, wenn es auch kompliziert geht.
Für die Auswertung hätte ich nichts gebaut, sondern einfach per ODBC mit Excel die zu betrachtenden Daten geladen, schön formatiert und auswertbar. Ich wäre auch nicht auf 4K beschränkt. Es gibt schließlich auch längere Zeilen.

Oder unser BI-Tool mit Archiv-/History-Funktion um genau dieses tun zu können;-).