View Full Version : Daten variabel dem richtigen Feld zuordnen
Folgendes Problem:
In einer Datei (Datei1) stehen:
Artikelnummer, Merkmal und Merkmalsausprägung.
Jede Artikelnummer kommt darin n-mal vor. Je nachdem wieviele Merkmale für diesen Artikel gefüllt sind.
Aus dieser Datei möchte ich eine Datei machen, in der jeder Artikel nur noch 1x vorkommt und die Merkmalsausprägungen spaltenorientiert gefüllt sind.
Um das ganze variabel zu halten für künftig neu angelegte Merkmale, hab ich folgendes gemacht.
- Merkmalsstamm lesen und DDS füllen mit Feldnamen und Länge der Felder.
- Datei umwandeln (Datei2) (per CL zur Laufzeit)
- Nun lese ich die Datei1 und möchte anhand des Merkmals dieses Satzes die Merkmalsausprägung in die Spalte moven, die den gleichen Namen hat wie das Merkmal dieses Satzes.
Bsp.: In Datei1 steht:
Artikelnummer 00000004 Merkmal LAENGE Ausprägung 1200
--> 1200 soll in Spalte LAENGE von Datei2 gemovt werden
Nächster Satz:
Artikelnummer 00000004 Merkmal BREITE Ausprägung 600
--> 600 soll in Spalte BREITE von Datei2 gemovt werden
usw..
Write in Datei2, wenn sich Artikelnummer in Datei1 ändert.
Ich dachte, das wär ganz simpel, aber jetzt komme ich nicht darauf, wie man das macht.
Sowas kannst Du nur mit dynamischem embedded SQL machen.
Birgitta
RobertMack
18-07-12, 10:36
Nur SQL? Wenn man nur einen Hammer hat, sieht jedes Problem wie ein Nagel aus...
1) DS-1, die Lfd. Nummer + Artikelnummer enthält
2) DS-2 mit Lfd. Nummer + Artikelnummer + Felder aus Datei2, OCCURS auf lfd. Nummer
2) Leseschleife um Datei1, Lookup in DS: vorhanden=Artikelnummer rein, nicht vorhanden: DS-1 Vorkommen plus 1, Artikelnummer rein
3) Leseschleife um Datei 2, mit Artikelnummer Vorkommen in DS-1 suchen, mit Occur in DS-2 Feld aktualisieren
4) 1 DO (max. Vorkommen DS-1), OCCUR, fortschreiben
5) Monitor oder Commit drum rum
In der Annahme, dass die Keys passen ;-)
RobertMack
18-07-12, 10:48
Oder, falls die Anzahl der Sätze zu groß ist: temp. Arbeitsdatei3 - nicht mehr ganz zeitgemäß, aber noch nicht verboten :D
Das würde m.E. doch nur dann funktionieren, wenn die Merkmale bereits vorher in den richtigen Spalten stehen würden.
Ich muß aber anhand des Inhaltes des Feldes MERKMAL
die Merkmalsausprägung in die entsprechende Spalte schreiben.
Nach dem Motto:
if MERKMAL = 'LAENGE'
move Merkmalsausprägung nach LAENGE
endif
und das für jedes MERKMAL.
Aber das ist halt dann nicht mehr dynamisch und muß bei neuen Merkmalen angepaßt werden.
Das würde m.E. doch nur dann funktionieren, wenn die Merkmale bereits vorher in den richtigen Spalten stehen würden.
Ich muß aber anhand des Inhaltes des Feldes MERKMAL
die Merkmalsausprägung in die entsprechende Spalte schreiben.
Nach dem Motto:
if MERKMAL = 'LAENGE'
move Merkmalsausprägung nach LAENGE
endif
und das für jedes MERKMAL.
Aber das ist halt dann nicht mehr dynamisch und muß bei neuen Merkmalen angepaßt werden.
Deshalb hatte ich SQL vorgeschlagen.
Anstatt eine physische Datei zu erstellen würde ich eine SQL View generieren.
Angenommen die Datei hat 3 Spalten: Artikel-Nr. ArtNr, Merkmal MRK, Wert Wert.
Dann könnte die View etwa so aussehen:
C
reate View MySchema/MyView
as Select ArtNr, Max(Case When MRK = 'A' Then Wert Else '' End) as MrkA,
Max(Case When MRK = 'B' Then Wert Else '' End) as MrkB,
Max(Case When MRK = 'C' Then Wert Else '' End) as MrkC,
...
Max(Case When MRK = 'X' Then Wert Else '' End) as MrkX
From MySchema/MyTable
Group By ArtNr;
Die Daten sind immer aktuell, da eine View eine logische Sicht auf die Daten darstellt. Es wäre sogar möglich die Spalten in unterschiedlichen Datentypen und Längen auszugeben. Sofern neue Merkmale hinzukommen, das SQL-Statement entsprechend anpassen und die View neu erstellen.
Auf die View kann mit (embedded) SQL und sogar mit Query/400 zugegriffen werden.
Im Bedarfsfall könnte basierend auf dem gleichen SELECT-Statement natürlich auch eine physische Datei (bzw. SQL Tabelle) erstellt werden.
Birgitta
Aber damit bräuchte ich auch genausoviele case-Abfragen wie im RPG if-Abfragen. Und ich müßte bei neuen Merkmalen das SQL anfasssen.
Ich wollte eigentlich sowas:
Datei1 hat 3 Spalten:
Artikel, Merkmal, Wert
Aus den unterschiedlichen Merkmalen erzeuge ich per PGM eine DDS uns wandle die um in eine PF.
Diese Datei hat die Spalten Artikel, Merkmal1, Merkmal2 etc. soviele Spalten wie es unterschiedliche Merkmale gibt.
Nun lese ich Datei1 und möchte Datei2 damit füllen, also die Daten sozusagen transponieren.
Schreibe Wert in das Feld von Datei2, das genauso heißt, wie der Inhalt des Feldes Merkmal in Datei1.
Sobald sich die Artikelnummer nach n Sätzen ändert, schreibe 1 Satz nach Datei2.
Das fett gedruckte sollte also idealerweise nur 1 Anweisung sein.
Logic IT-Services
19-07-12, 14:41
Du erstellst die ja eine DDS mit den entsprechenden Feldern horizontal und compilierst die zur Runtime, richtig?
Dein Problem ist nun, dass Du wohl die Felder hast, aber nicht weisst welcher Wert (Merkmal) darin stehen sollte...
Mein Vorschlag:
1. Headerfile erstellen mit nur einem Datensatz (Array)
Pro Merkmal 1 Feld (Name egal, aber Benamsen COLHDG nach dem Merkmal)
und Merkmaltext als DFT-Value
DDS entsprechend aufbereiten und einen Record schreiben
2. Artikelfile erstellen mit Artikelnummer und Raster aus Header.
Verarbeitung:
Arrays erstellen im Programm und mit einem Scan des Merkmals (Headerfile) die Position ermitteln. Felder entsprechend moven - Write und fertig.
Ist ein bisschen hölzern und muss halt jeweils aufbereitet werden aber ich würde diesen Ansatz verfolgen. Ist das dynamisch genug?
Ach ja, die Queries bzw. nachfolgende RPG-PGM's ändern sich halt dann nicht dynamisch. Stichwort: Levelcheck, aber für Export to Excel alleweil gut.
Just my 5ct
Birgittas Lösung ist M.E. einfacher/schöner.
Daher würde ich anstatt 'automatisch eine DDS zu schreiben'
lieber "automatisch die SQL-Source" schreiben.
Die Source dann, nach einem Drop View, mit RUNSQLSTMT ausführen, fertig.
Aber das sit natürlich Geschmacksache
Robi
Logic IT-Services
19-07-12, 15:09
Birgittas Lösung ist M.E. einfacher/schöner.
Einverstanden.
BTW. das Headerfile könnte man sich auch sparen und nur mit dem Array arbeiten.
Aber eben, ist halt ein Schnellschuss... ;-)