View Full Version : Problem mit log.File
Hallo Forum.
Ich habe eine log.File mit mehreren Schlüsselfeldern
mit CRTLF erstellt.
Da diese LF eine völlig andere Satzreihenfolge liefert, habe ich mit DSPFD die File-Definition angeschaut.
Darin taucht plötzlich der Hinweis auf eine weitere LF mit den gleichen,
jedoch anders angeordneten Schlüsselfeldern auf. Also benutzt diese
LF eine andere LF ??
Wer hat dazu eine plausible Erklärung?
Gruss Joe
Hi Joe,
was bedeutet der Satz
Da diese LF eine völlig andere Satzreihenfolge liefert, habe ich mit DSPFD die File-Definition angeschaut.
Wie hast du dir die Reihenfolge angeschaut ?
Robi
Der DB-Optimizer verwendet ggf. andere LF's mit zur Optimierung der Schlüsselfolge.
Das hat keinen Einfluss auf die Sortierung.
Wenn du z.B. eine neue LF mit einer identischen Schlüsselfolge erstellst, die bereits vorhanden ist, verweist diese LF einfach auf die andere.
Damit ist der Update von LF's schneller da ja nicht nur neue Schlüssel erstellt sondern auch Schlüssel geändert werden können.
Hi Joe,
vielleicht hilft es auch, mit DSPDBR einmal zu schauen, welche (menge) an LF du dranhängen hast.
Man muss ja Rom nicht mehrmals aufbauen.
Gruss, Brownie ;)
Hallo Robi, Hallo Fuerchau.
Mir ist schon bekannt, dass der SQL Optimizer evtl. vorhandene
Zugriffspfade sucht und benutzt.
Aber:
Bei meinem Problem sieht die Praxis lt. DSPFD anders aus:
Schlüsselfelder der Log. Datei die das RPG-Prog. benutzen soll:
LF001
Firma: 001
Lager: 001
Artikel: 4711
Zugang: 20050410
Platz: 12345
Kriterium01: 01
Kriterium02: 14
Kriterium03: 01
Lf wurde mit dieser Beschreibung erstellt.
In der DSPFD für diese Datei erscheint:
Datei, der der Zugriffspfad gehört . . : YLF002
Beschreibung der LF002
Firma: 001
Lager: 001
Artikel: 4711
Platz: 12345
Kriterium01:01
Kriterium02:14
Kriterium03:01
Zugang: 20050410
Somit hat der Sql-Optimizer zwar eine LF mit identischen
Schlüsselfldern erkannt, aber die Reihenfolge ist nicht korrekt.
Nach erneuter Umwandlung der LF001 gab es kein Probleme mehr.
Vielleicht schwer zu verstehen?!
Infos vom IBM-Support werde ich bekanntgeben.
Danke
Mir ist schon bekannt, dass der SQL Optimizer evtl. vorhandene Zugriffspfade sucht und benutzt.
Der Query Optimizer sucht nicht nur eventuell, sondern immer nach dem optimalen Zugriffs-Pfad, wenn ein SQL-Statement (oder Query-Anweisung) ausgeführt wird. Übrigens wenn eine logische Datei in einem SQL-Statement angegeben wird, wird die Abfrage vom Query Dispatcher gnadenlos an die CQE (classical Query engine) zurückgegeben, so dass die Neuerungen (Verbesserungen) der SQE (SQL Query Engine) nicht zum Zug kommen.
Der Query Optimizer kommt jedoch nicht zum Einsatz, wenn eine logische Datei mit native I/O in RPG verarbeitet wird.
DSPFD hat auch nichts mit dem Query Optimizer zu tun.
Die Geschichte mit Shared Data Path hat einfach nur den Vorteil, dass bei einer Daten-Änderung nur ein Daten-Pfad angepasst werden muss und nicht so viele wie logische Dateien mit dem gleichen Daten-Pfad (sprich Schlüssel) vorhanden sind.
Da nach erneuter Erstellung der logischen Datei alles in Ordnung ist, vermute ich einen Kompilierungs-Fehler (z.B. falsche Bibliotheks-Liste) beim ersten Umwandeln.