Pest oder Cholera

[KingofKning]

Danke,
ich muss darüber nachdenken, will die Daten eigentlich mit Cobol weiterverarbeiten.

Melde mich morgen wieder.

PS immer noch V5R4

[B.Hauser]

will die Daten eigentlich mit Cobol weiterverarbeiten.

Das ist doch kein Problem, Du liest die Daten mit (embedded) SQL in eine Datenstruktur oder einzelne Host-Variablen und verarbeitest die Werte weiter mit Cobol.

Birgitta

[Robi]

ggf hab ich das Problem noch nicht verstanden, wenn doch, dann mach ein Index
mit Kundennr (aufsteigend) und g.ab.Datum absteigend auf die View, das geht.
(Datum als Datum oder numerisch JJJJMMTT)
Beim Zugriff mit 'Kunde und Datum' (setll und read) hast du immer den zu Zeitpunkt Datum gültigen Satz.
Robi

[KingofKning]

Hallo,
die Original-Datei hat über 300.000 Datensätze. Mich interessieren aber nur die Datensätze die Gültigkeitsdatum >= dem Tagesdatum bzw. den Wert 99999999 (immer gültig) haben.
Aufbau:

Kunden-Nummer Artikel-Nummer Preis Datum
1081_________ 123 __________0,70 14.12.2014
1081_________ 124__________ 0,99 15.12.2014
1081_________ 124__________ 1,05 10.12.2014

Mit der View habe ich halt den Vorteil immer nur aktuelle Sätze zu haben, mit der LF kann ich zwar auf den Kunden positionieren. Muß mir aber merken welchen Artikel ich gerade hatte und alle Datensätze die vom selben Artikel aber jüngeren Datums sind überlesen.

Da finde ich die View einfach schöner.

Mit embedded SQL in Cobol muß ich mal schauen. Ganz bestimmt eine tolle Sache wenn es mal läuft, aber bis dahin gibt es doch den ein oder anderen Stolperstein....

GG

[Robi]

Ok, verstanden,
Dann zu deiner ursprünglichen Frage:
Ja, du kannst einen Index auf die View legen oder die View im SQL mit order by lesen --> Birgitta's Antwort
SQL verwendet dann alles an LF/INdex was er gebrauchen kann oder sortiert selber.

(meine Cobol Zeit ist gefühlte 100 Jahre her, aber ich denke einen Index kannst du auch im Cobol 'native' verarbeiten)
Robi

[BenderD]

Hallo,
die Original-Datei hat über 300.000 Datensätze. Mich interessieren aber nur die Datensätze die Gültigkeitsdatum >= dem Tagesdatum bzw. den Wert 99999999 (immer gültig) haben.
Aufbau:

Kunden-Nummer Artikel-Nummer Preis Datum
1081_________ 123 __________0,70 14.12.2014
1081_________ 124__________ 0,99 15.12.2014
1081_________ 124__________ 1,05 10.12.2014

Mit der View habe ich halt den Vorteil immer nur aktuelle Sätze zu haben, mit der LF kann ich zwar auf den Kunden positionieren. Muß mir aber merken welchen Artikel ich gerade hatte und alle Datensätze die vom selben Artikel aber jüngeren Datums sind überlesen.

Da finde ich die View einfach schöner.

Mit embedded SQL in Cobol muß ich mal schauen. Ganz bestimmt eine tolle Sache wenn es mal läuft, aber bis dahin gibt es doch den ein oder anderen Stolperstein....

GG

... selbst das geht mit einer DDS LF, Denormalisierung ist das Zauberwort; Du brauchst doch nur eine Datei mit einem Satz, wo Du um 0:00 Uhr das aktuelle Datum reinschreibst.

D*B

[Fuerchau]

Wenn du kein embedded SQL verwenden willst (oder kannst) hast du diesbezüglich tatsächlich ein Problem.
Per DDS kannst du zwar eine LF sortiert nach Datum definieren, aber wenn du per Gruppenwechsel-Logik nach Kunde/Artikel arbeiten musst, kannst du dies nicht per simpler LF definieren.

Hier bieten sich 2 Möglichkeiten an:
1. Gib die View mit z.B. einen QMQRY in eine temporäre Tabelle mit Index nach Kunde/Artikel aus.
2. Verwende die COBOL-Anweisung SORT, gib als Input die Datei und als Output eine Prozedur an.

[cbe]

oder ein OPNQRYF direkt vor dem Aufruf?
Frag mich aber nicht nach Details, das habe ich zum letzten Mal vor gut 15 Jahren mal gemacht - würde aber zu Deinem OS400-Release passen

Gruß, Christian

[BenderD]

... ist zwar alles schon ewig her, aber:
ich kann doch per DDS zwei Tabellen miteinander verjoinen und mit DYNSLT in einer COMP Bedingung zwei Felder aus unterschiedlichen Tabellen vergleichen und wenn in der einen - nicht eben zufällig - das Datum von heute im passenden Format drinsteht ...

PS: das geht doch selbst bei Query: erst mit einem QMQRY das aktuelle Datum, oder den Monat, oder whatever in eine Auswahltabelle schreiben, die dann im eigentlichen Query mit dazu geholt wird...