[NEWSboard IBMi Forum]
Seite 1 von 2 1 2 Letzte
  1. #1
    Registriert seit
    Nov 2004
    Beiträge
    325

    Protokollierung von Stammdaten

    Hallo *all,


    nach Jahrzehnten merkt man – obwohl immer darauf hingewiesen wurde – das man ja mal eben Stammdaten protokollieren möchte.


    Also Zustand vorher/nachher. Kein Problem, löst man ja – wenn man keine Journalisierung hat – über Trigger.


    Also Protokolldatei gemacht, Triggerprogramm gemacht, fertig. Aber Pustekuchen, wie bekommt man jetzt den Satzinhalt per Externer DS in ein Alphafeld mit einer Länge von derzeit 4096 bytes rein.



    Denn Feld = Satzformat funktioniert zwar generell, aber Dezimalfelder……. Muss man jetzt jedes Feld aufbereiten?


    Feld von x bis y = aufbereitet usw.?



    Ich such schon seit gestern, finde aber nichts. Ich sehe den Baum vor lauter Wald nicht.


    mfg


    DKSPROFI

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  3. #3
    Registriert seit
    Nov 2004
    Beiträge
    325
    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

  4. #4
    Registriert seit
    Jun 2001
    Beiträge
    1.973
    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
    Das Notwendige steht über dem technisch machbaren.
    (klingt komisch, funktioniert aber!)

  5. #5
    Registriert seit
    Nov 2004
    Beiträge
    325
    Moin Robi,

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

    mfg

    DKSPROFI

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  7. #7
    Registriert seit
    Nov 2004
    Beiträge
    325
    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

  8. #8
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  9. #9
    Registriert seit
    Nov 2004
    Beiträge
    325
    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

  10. #10
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    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;-).
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  11. #11
    Registriert seit
    Aug 2001
    Beiträge
    2.644
    Zitat Zitat von DKSPROFI Beitrag anzeigen
    Hallo *all,
    nach Jahrzehnten merkt man – obwohl immer darauf hingewiesen wurde – das man ja mal eben Stammdaten protokollieren möchte.
    Also Zustand vorher/nachher. Kein Problem, löst man ja – wenn man keine Journalisierung hat – über Trigger.
    Warum hat man kein Journal? ;-)
    Je nach Branche muss man bei einem Triggerprogramm noch qualifizieren, daß dieses auch funktioniert.

    -h
    www.RZKH.de
    IBM Champion 2022, 2023, 2024
    IBM i Community Advocate https://www.youracclaim.com/badges/6...c-7ad4ba147af6
    Common / CEAC
    http://pub400.com

  12. #12
    Registriert seit
    Nov 2004
    Beiträge
    325
    Moin,

    danke an Euch allen. Ganz pragmatsich und einfach habe ich es gelöst. Leider können wir die Journalisierung bei uns nicht einschalten, da der überwigenden Teld der Dateien noch /36er Dateien sind.

    mfg

    DKSPROFI

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •