OPNQRYF - Indexerstellung

[IBSCPO]

Hallo,
ich habe eine Frage.
Wenn ein OPNQRYF über eine PF läuft, dann wird immer ein INDEX über die Datei erstellt. Der OPNQRYF - String hat auch mehrere Key - Felder.

Da die INDEX - Erstellung immer sehr lange dauert, habe ich eine LF über die PF erstellt. Nun habe ich das Programm mit den OPNQRYF gestartet, aber der Index wird wieder aufgebaut. Obwohl ein Index durch die LF vorhanden ist.

Warum benutzt der OPNQRYF den Index der LF nicht?

Kann es sein, dass ein OPNQRYF keinen vorhandenen Index durch eine LF benutzt, sondern "immer" einen eigenen aufbaut?

Danke für die Hilfe..

Guß Carsten

[Fuerchau]

Das hängt nun mal stark von der Selektion ab, ob ein Index verwendet werden kann.

[IBSCPO]

Das hängt nun mal stark von der Selektion ab, ob ein Index verwendet werden kann.

Wenn Du dir den String anschaußt, was meinst Du, ist das so ein Fall?


1 'OPNQRYF FILE((SROPST)) QRYSLT('PSPERI =%RANGE(000000 200804)'
61 ' & PSDIM1 =%RANGE("42100 " "42100
121 ' ") & PSTYPE =%RANGE("1" "3") & PSPERI *NE 000000') KEYFLD'>>
181 '((PSDIM1) (PSPERI) (PSDIM2) (PSDIM3) (PSDIM4) (PSDIM5) (PSDI'>>
241 'M6) (PSDIM7) (PSDIM8) (PSVODT) (PSVOTY) (PSVONO) (PSTCUR)) '>>
301 'MAPFLD((XZPERI 'PSPERI' *ZONED 6 0) (XCPERI 'XZPERI' *CHAR 6'>>
361 ') (XXYEAR '%SST(XCPERI 1 4)' *ZONED 4 0) (XXPER '%SST(XCPER'421 'I 5 2)' *ZONED 2 0))

Die Keyfelder sind rot gekennzeichnet.

Die logische Datei sieht so aus:

R PST PFILE(SROPST)

K PSDIM1
K PSPERI
K PSDIM2
K PSDIM3
K PSDIM4
K PSDIM5
K PSDIM6
K PSDIM7
K PSDIM8
K PSVODT
K PSVOTY
K PSVONO
K PSTCUR

So müsste es doch funktionieren.

Carsten

[Fuerchau]

Durch den Range-Select ist ein vorhandener Key nicht verwendbar.

Das beschreiben auch im Wesentlichen die Performancehinweise, dass Keys nur bei eindeutigen Vergleichen (>, <, =) verwendet werden.
Da bei Range, und hier gleich mehrfach, ja aus unterschiedlichen Quellen ausgewählt wird.

Ggf. kannst du einen Performancegewinn erreichen, wenn du weitere einzelne LF's (Indexe) erstellst:
PSPERI
PSTYPE

Über PSDIM1 gibts schon einen.
Der Optimizer kann dann ggf. per Binär-Mapping arbeiten.
Allerdings ist das kein Versprechen.

Warum Range PSPERI von 0000 um dann 000 auszuschließen ?

[IBSCPO]

Das hängt nun mal stark von der Selektion ab, ob ein Index verwendet werden kann.

Ich habe die Selektion schon entfernt. Mir kamm es auch komisch vor. Ich habe auch noch weiter LF's erstellt. Aber der OPNQRYF baut immernoch einen Index auf.

Müssen eigentlich alle Keyfelder in einem Index vorhanden sein? Ich meine nicht. Aber beim OPNQRYF ???

Danke schon mal..

Carsten

[Fuerchau]

Ich denke, hier hilft ggf. auch der DEBUG-Modus.
Also vor Aufruf mit
STRDBG UPDPROD(*YES)
den Modus starten.
Wenn das Programm dann gestartet ist, ggf. im Joblog nach Hinweisen des Optimizers suchen.
ENDDBG beendet den Modus.

Wenn das mit OPNQRYF nicht klappt, ggf. im Debug-Modus per STRSQL einen Select zusammenbauen, der dem OPNQRYF entspricht.

Ansonsten würde ich mich eigentlich vom OPNQRYF verabschieden und das Ganze direkt mit SQL angehen.
Da bekommt man klarere Aussagen.

[IBSCPO]

Danke schon mal für die Hilfe.

Kannst Du mir jetzt vielleicht kurz auf die Sprünge helfen, wie ich mit SQL in einem CL das gleiche Resultat erreiche?

Hinweis: Nachdem der OPNQRYF die Daten zusammengestellt hat, werden die temporären Daten in einen RPG Programm weiterverarbeitet. OVRDBF SHARE(*YES) wird für die Datei dann auch gesetzt.

Das RPG Programm erzeugt dann eine Liste.

Gruß Carsten

[Fuerchau]

SQL in CL geht nicht.
Du musst da schon ein SQLRPG / SQLRPGLE erstellen und die Dateibefehle durch SQL ersetzen.

Wenn das RPG allerdings mit InputPrimary und Zyklus arbeitet, kannst du das vergessen und musst damit halt so leben.

[IBSCPO]

Danke für die Antwort.

Eine frage noch:

Wenn ich anstatt des OPNQRYF eine SQLRPG Programm verwende, kann das REPORT Programm dann auf die Daten zugreifen?

Wenn ja, wie stelle ich das am besten an? Hast Du eine Beispiel?


Carsten

[Uwe Moesel]

RUNSQLSTM führt ein SQL-Statement, dass sich in einem Source-File befindet, aus.