SQL View mit Cobol bearbeiten

[KingofKning]

Hallo *all,
ich habe mir eine View gebaut und greife damit aus Cobol klassich zu.
Das Problem ist jetzt das ich die Datei ca. 2.000 mal lesen muß.

Da die Datei keine Index-Datei ist, mache ich immer eine Open & Close um sie von vorne zu lesen.
Bei Index-Datei würde ich ja ein Low-Value in den Satz stellen und Start Key not < .... machen.
Beu sequentiellen Dateien geht das ja nicht.

1. Bringt das überhaupt was die Datei irgendwie als Index Datei umzumodeln (Wobei ich noch nicht weiß wie)
2. Würde ein Zugriff per SQL was bringen?

GG

[BenderD]

Hallo *all,
ich habe mir eine View gebaut und greife damit aus Cobol klassich zu.
Das Problem ist jetzt das ich die Datei ca. 2.000 mal lesen muß.

Da die Datei keine Index-Datei ist, mache ich immer eine Open & Close um sie von vorne zu lesen.
Bei Index-Datei würde ich ja ein Low-Value in den Satz stellen und Start Key not < .... machen.
Beu sequentiellen Dateien geht das ja nicht.

1. Bringt das überhaupt was die Datei irgendwie als Index Datei umzumodeln (Wobei ich noch nicht weiß wie)
2. Würde ein Zugriff per SQL was bringen?

GG

... was bringt das, die Datei ca. 2000 mal zu lesen?

D*B

[Robi]

Bringt das überhaupt was die Datei irgendwie als Index Datei umzumodeln (Wobei ich noch nicht weiß wie)

Eine view ist wie ein LF ohne index. da is nix um zu modeln

Würde ein Zugriff per SQL was bringen?

ja, natürlich
select felder from view where ... order by ...
verwendet, falls passend die LF/Indexe der PF's.
Passt keiner sortiert SQL

Ob und vor allem Warum du 2000 mal 'durchlesen' mußt verstehe ich auch nicht.
Aber das Leben stellt einem manchmal solche komischen Aufgaben.
GGf ist mit dem direkten zugriff via SQL über
set
select ... into ...
oder fetch
das Problem schon entschärft.

Sql lesen ist nur bei Einzelsatzverarbeitung (Ersatz für chain) nicht so schnell/im coding komfortabel wie 'native' lesen.

Robi

[KingofKning]

Ich muß für ca. 2000 Kunden die Sonderpreise für unsere Artikel ermitteln und in eine Datei schreiben.
Über das SQL muß ich nochmal nachdenken bin gedanklich noch nicht bei dem Lösungsansatz.

GG

[B.Hauser]

Wie sieht denn die View-Definition aus?

Sofern die View nur auf einer einzigen Tabelle basiert und keine GROUP BY Anweisungen oder Zugriff auf "handgestrickte" User Defined Functions ... es gibt noch ein paar andere Restriktionen
is es evtl. möglich einen SQL Index mit Where-Bedingungen, neuen Spalten und dem passenden Schlüssel zu generieren.

Indices können zwar mit SQL nicht direkt angesprochen werden, wohl aber mit native I/O wie ganz normale geschlüsselte logische Dateien verarbeitet werden.

... ohne jedoch die View-Definition gesehen zu haben, kann man an dieser Stelle außer embedded SQL nichts empfehlen.

... ich würde eine solche Anforderung wie Du sie hast, so wie so nur mit SQL lösen.

Birgitta

[KingofKning]

So:
CREATE VIEW DAT008 AS SELECT SOID1, SOID2, SODNBI, SODNVO, SOID4, SO
EIPR, SOSA16, SOEIP2 FROM SON01PF WHERE SOFA = 1 AND SOSTS = 0
AND SOABKZ = 0 AND SOJHVO = 1 AND SOEIPR > 0 AND (SODNBI >= YEAR(CU
RRENT DATE)*10000 + MONTH(CURRENT DATE)*100 + DAY(CURRENT DATE)) GRO
UP BY SOID1, SOID2, SODNBI, SODNVO, SOID4, SOEIPR, SOSA16, SOEIP2 RC
DFMT DAT008SATZ

Für ne DDS Datei zu kompliziert

[B.Hauser]

Dieses SQL-Statemen kann weder in eine DDS beschreibene logische noch in einen SQL Index konvertiert werden, allein schon deshalb, weil Du einen Group By und das special Register CURRENT_DATE verwendet hast.

Ich frage mich wirklich, warum Du Dich mit Händen und Füßen gegen die Verarbeitung mit embedded SQL wehrst.

Mit embedded SQL kannst Du gezielt die Daten-Sätze für die einzelnen Kunden auslesen und dann verarbeiten.
Evtl. wäre es sogar möglich die View mit einer weiteren Tabelle (sofern vorhanden) zu verküpfen und nur die gewünschten Kunden selektieren.

Sofern Du die richtigen Zugriffswege hast, sollte das Ganze auch performant laufen.
Wenn es eine Eintagsfliege ist und Du keine neuen Indices anlegen willst, musst Du halt etwas länger warten bis das Programm fertig ist.

Birgitta

[KingofKning]

Ich sträube mich nicht, sonst würde ich ja nicht fragen.
Die Aufgabenstellung ist das ich eine Schnittstellen-Datei mt alle Kunden/Artikeln füllen muß. Ergebnis sind 191.000 Sätze.

Habe 1.000 Kunden und 2.000 Artikel / Preis mit Gültigkeitsdatum.

Hole mir also den ersten Kunden, und schaue dann ob ich in der Datei für diesen Kunden einen Artikel mit Sonderpreis habe und schreibe diesen dann in eine Datei weg um diese später zu in eine Text-Datei zu exportieren.

Die Laufzeit beträgt zur Zeit 2 Stunden. Was schnelle Tests bei Änderungen unmöglich macht.

Das Programm läuft täglich um immer alle aktuellen Preise zu haben.

Ohne aktiven Diskussionspartner bekomme ich das Problem zwar gelöst aber halt nicht die Optimale Lösung. Ich werde daher über das Problem nochmals nachdenken.

Danke erstmal für die Hinweise.

GG

[B.Hauser]

1. Würde ich die View ohne diese Umrechnung des Tages-Datums in einen numerischen Wert erstellen. Das numerische Datum solltest Du dann vor der Verwendung der View in einer Host-Variablen ermitteln und in Deinem Programm als zusätzliche WHERE-Bedingung hinzufügen.

2. Sofern Du das (numerische) Datum weiterhin in der View verwenden möchtest, solltest Du Dir eine Globale Variable anlegen, in der das numerische Tagesdatum ermittelt wird. Globale Variablen werden beim ersten Aufruf innerhalb eines Jobs aktualisiert.
Globale Variablen können in Views verwendet werden.

3. Würde ich die View direkt mit dem Kundenstamm (oder woher die Kunden auch immer kommen) verknüpfen und alles in einem einzigen Cursor verarbeiten.

4. Prüfe, ob für die Verarbeitung auch die richtigen Zugriffswege vorhanden sind, oder ob vielleicht eine Index-Empfehlung vorliegt.
STRDBG vor Ausführung und dann Blick ins Joblog oder Visual Explain.
Es sollte zumindest ein Zugriffsweg vorhanden sein in dem das aktuelle Datum (führend) enthalten ist. Ggf. könnten auch die sonstigen WHERE-Bedigungen als WHERE-Bedigungen in dem Index hinterlegt werden (Syntax muss allerdings übereinstimmen).

SQL ist nur auf den ersten Blick einfach!
Deshalb empfiehlt die IBM ja inzwischen "Database Adminsitrators" bzw. "Database Engineers".
... es soll übrigens auch Firmen geben, die SQL auch im Hinblick auf solche Probleme schulen

Birgitta

[KingofKning]

Jo danke, werde ich drüber nachdenken.
Und im nächsten Leben würde ich auch gerne in einer richtigen Firma arbeiten wo die EDV nicht als notwendiges Übel betrachtet wird.

Es müßen ja nicht direkt die Zeiten sein wo die Jungs noch mit Kitteln über den Flur gegangen sind.

Aber in den 10 Jahren die ich hier bin wurden genau 0€ in Schulungen investiert.

Und da ich alleine für die komplette EDV von der Telefonanlage über die Server und Netzwerke bis zum Indutrieroboter zuständig bin kann man sich vorstellen das da wenig Zeit bleibt um sich intensiv einzuarbeiten..

GG