View Full Version : Gruppenwechsel / Änderung Datensatz
Hilfe, stehe etwas neben mir :-)
Suche Lösung für RPGLE
Problem: READ BESTELLUNG
- Änderung des Datensatzes
UPDATE BESTELLUNG
Es soll eine Historie erstellt werden, die nur geschrieben wird wenn sich tatsächlich in BESTELLUNG etwas ändert.
wie kann ich am einfachsten mit einer Datenstruktur arbeiten?
danke für eure Hilfe
Das löst du am einfachsten mit einem Trigger.
Durch den Vergleich After/Before-Immage (falls nicht alle Felder relevant sind) kannst du dann ein Kopie wegschreiben mit ggf. Ergänzung Timestamp o.ä.
Das gewährleistet, dass auch Änderungen auf einem anderen Weg (SQL, UPDDTA, ODBC) festgehalten werden.
Alles andere ist da eher weniger hilfreich, da ggf. nicht sauber implementiert.
Ansonsten kannst du mit "qualified" Strukturen arbeiten, wobei du bereits bei den F-Bestimmungen die Ziel-DS qualified angeben solltest. Nach dem Read die DS kopieren.
Dann kannst du per DS-Vergleich die Änderung feststellen.
Zu beachten ist allerdings dann, dass alle Feldreferenzierungen dann qualified erfolgen müssen.
Das ist insbesonders dann problematisch, wenn man identische Feldnamen in verschiedenen Dateien (PF und DSPF oder PRTF) verwendet um sich den Move zu sparen.
dschroeder
25-09-12, 13:15
Wir haben das gleiche Problem und es folgendermaßen gelöst:
1. Definition einer externen Datenstruktur, die auf BESTELLUNG basiert.
2. Eine Alpha-Variable definieren, die immer die Länge der Datenstruktur hat und die vor der Änderung mit dem alten Datensatzinhalt gefüllt wird.
3. Vor dem Update einen Vergleich des Datensatzes mit dem gesicherten Alphafeld.
Hier der Code:
D BestellSatz E DS EXTNAME(bestellung)
D BestellKopie S like(BestellSatz)
read Bestellung // dadurch wird Struktur BestellSatz gefüllt
BestellKopie = BestellSatz // Alten Datensatzinhalt sichern
- Änderung des Datensatzes (oder auch nicht)
if BestellSatz <> BestellKopie
writeHistorie;
endif
Bei Datenstrukuränderungen (z.B. wenn in der Tabelle BESTELLUNG ein neues Feld eingefügt wird) reicht es, das Programm neu zu kompilieren, da die Alpha-Variable mit like definiert ist und damit immer die richtige Länge hat.
Bei uns klappt das Verfahren seit Jahren problemlos.
Das mit dem Trigger geht natürlich auch. Dabei hat man den Vorteil, dass alle Änderungen (z.B. auch mit SQL) die Historie fortschreiben
Gruß,
Dieter
danke für die Hilfe
werde mich heute Abend dran setzen !!:)
Wir haben das gleiche Problem und es folgendermaßen gelöst:
1. Definition einer externen Datenstruktur, die auf BESTELLUNG basiert.
2. Eine Alpha-Variable definieren, die immer die Länge der Datenstruktur hat und die vor der Änderung mit dem alten Datensatzinhalt gefüllt wird.
3. Vor dem Update einen Vergleich des Datensatzes mit dem gesicherten Alphafeld.
Hier der Code:
D BestellSatz E DS EXTNAME(bestellung)
D BestellKopie S like(BestellSatz)
read Bestellung // dadurch wird Struktur BestellSatz gefüllt
BestellKopie = BestellSatz // Alten Datensatzinhalt sichern
- Änderung des Datensatzes (oder auch nicht)
if BestellSatz <> BestellKopie
writeHistorie;
endif
Bei Datenstrukuränderungen (z.B. wenn in der Tabelle BESTELLUNG ein neues Feld eingefügt wird) reicht es, das Programm neu zu kompilieren, da die Alpha-Variable mit like definiert ist und damit immer die richtige Länge hat.
Bei uns klappt das Verfahren seit Jahren problemlos.
Das mit dem Trigger geht natürlich auch. Dabei hat man den Vorteil, dass alle Änderungen (z.B. auch mit SQL) die Historie fortschreiben
Gruß,
Dieter
Hallo!
Ich hab das auch schon mehrmals so gemacht, aber statt eines Alpha-Feldes eine zweite DS mit dem Schlüsselwort PREFIX verwendet. Dadurch bekommen alle Variablen-Namen ein Prefix z.B. 'H' für Hilf o.ä. vorangestellt.
Dann braucht man nicht mit qualified arbeiten und kann die DS auch mit Like definieren. Vor dem Update wird die DS1 in die DS1H gemoved und mit einem Chain der Satz aus der DB in DS1 gelesen
Der Vergleich ist dann durch ein einfaches if ds1 <> ds1h erledigt. Wenn Unterschiede herrschen, DS1H zurückmoven und damit die DB updaten.
Gruß,
Günter
Ich hab das auch schon mehrmals so gemacht, aber statt eines Alpha-Feldes eine zweite DS mit dem Schlüsselwort PREFIX verwendet. Dadurch bekommen alle Variablen-Namen ein Prefix z.B. 'H' für Hilf o.ä. vorangestellt.
Dann braucht man nicht mit qualified arbeiten und kann die DS auch mit Like definieren.
Die Geschichte mit dem Präfix klapp allerdings nur, wenn die neuen Feldnamen (inklusive Präfix) 10 Zeichen nicht überschreiten. Sofern die Feld/Spalten-Namen in der Datei/Tabelle 10 Zeichen lang sind, bekommst Du ein Problem.
Was ist übrigens Dein Problem mit qualifizierten Datenstrukturen?
Seit Release V5R2M0 kann man Datensätze direkt in (qualifizierte) externe Datenstrukturen oder Datenstrukturen die mit dem Schlüssel-Wort LikeRec oder LikeDS (basierend auf einer externen Datenstruktur) eingelesen werden. Die Datenstruktur wird dabei in Faktor 2 angegeben. Bei WRITE und DELETE und ab 7.1 sogar bei EXFMT kann ebenfalls eine Datenstruktur angegeben werden. Bei lokalen F-Bestimmungen ist eine Ausgabe und Verarbeitung über Datenstruktur sogar erforderlich.
Der Vergleich von qualifizierten Datenstrukturen kann ebenfalls mit Datenstruktur1 = Datenstruktur2 (bzw. Datenstruktur1 <> Datenstruktur2) erfolgen.
Die Übernahme von qualifizierten Datenstrukturen kann ebenfalls über EVAL Datenstruktur2 = Datenstruktur1 erfolgen. Besser ist allerdings an dieser Stelle EVAL-CORR (ab Release V5R4) zu verwenden.
Birgitta
Hallo Brigitta!
Stimmt natürlich, mit der Länge muß man aufpassen. Bei der Firma in der ich arbeite stammt noch vieles aus RPG III und da war sowieso bei 6 Zeichen für Feldnamen Schluß.
Auch stimmt es, daß es elegantere Lösungen für das Problem gibt. Qualifizierte DS hab ich auch schon verwendet.
Mir ging es bei dem Eintrag lediglich darauf hinzuweisen, daß man statt eines langen Charakter-Feldes auch eine zweite DS nehmen könnte. Mehr nicht.
Es zeigt sich immer wieder, daß es in der Programmiererei immer verschiedene Wege gibt, manche eleganter manche weniger, um zum Ziel zu kommen.
Trotzdem Danke für die Hinweise.
Günter