View Full Version : QDBCRTHA + QDBRUNHA API's
Das dürfte sogar noch länger dauern als die bisher verwendete Methode, da ja auch CPYF 2xOPEN/READ/WRITE/2xCLOSE benötigt und das 60x !!!
Ausserdem ist CPYF mit INCREL auch nicht gerade der schnellste.
Frank Hildebrandt
08-11-05, 13:11
In der F-Bestimmung kann man über des Schlüsselwort EXTFILE die Datei im Format "Bibliothek/Datei" angeben. Zusätzlich mit dem Schlüsselwort USROPN könnte man folgendermaßen vorgehen. Open Datei, Read Datei, Close Datei ... Das ganze dann natürlich für jede Bibliothek. Schneller als die Sache mit dem OVRDBF und dem DLTOVR ist das ganze mit Sicherheit.
In den F-Bestimmungen kann man leider keine LIB angeben und die Datei heißt ja in allen LIB's identisch, also sind zur Laufzeit 60 OVRDBF's erforderlich. Das Problem hierbei ist, mit welcher ID öffnet RPG denn die Datei ? Wenn ich EXTFILE angebe, dann doch sicherlich mit dieser ID und die ist 60 mal identisch !?
Und die OPEN/CLOSE dauern ja auch noch zusätzlich.
Die schnellste Variante wird tatsächlich SQL sein:
- Angabe der LIB
- OPEN nur beim 1. Aufruf
Man muss sich halt nur Mühe beim Tippen (60x) geben.
Hallo!
Vielleicht eine Kombination aus allem? :)
Zwei oder drei Multi-Format-LFs sortiert nach Artikelnummer, über diese dann (mittels QMQRYs oder RUNSQLSTM) jeweils ein INSERT der Datensätze des ausgewählten Artikels in eine temporäre Arbeitsdatei und im RPG-Programm dann mit dieser Arbeitsdatei arbeiten!?
Viele Grüße
Jürgen
Frank Hildebrandt
08-11-05, 13:54
Das Schlüsselwort EXTFILE akzeptiert auch eine Variable. Hier ein Beispiel.
f MyFile IF Disk ExtFile(QualMyFile) UsrOpn.
d QualMyFile 21 A
c Eval QualMyFile = 'LIB/FILE'
c Open MyFile
...
c Read MyFile
...
c Close MyFile
Das ganze noch in eine Schleife setzen und ab geht die Post. Lediglich bei der Kompilierung muss die Datei MyFile in der Bibliotheksliste zu finden sein.
Frank, dass müsste gehen, aber über die Performance sollte man sich nicht allzuviel Gedanken machen.
Frank Hildebrandt
08-11-05, 14:38
Aus dem Bauch heraus wage ich mal zu sagen, dass Winnileins Programm spürbar schneller läuft. Er macht ja auch immer einen OPEN und dann einen CLOSE. Die ganze Sache mit dem Overrides entfällt komplett. Und genau da liegt neben der OPEN/CLOSE Problematik der andere Performance-Fresser.
Sollten diese 60 Dateien alle von einem Programm fortgeschrieben werden, bietet sich doch die Anlage einer neuen Datei in einer Lib an. Keyfelder sollten Filiale und Artikelnr. sein. Vorteil wäre eine permanente Aktualisierung und einfacher, schneller Zugriff für ein Subfile-pgm.
Diese Idee könnte man forsetzen:
Einfachen Trigger auf die 60 Dateien legen, der bei Insert/Update/Delete eine Parallel-Datei mit Schlüssel LIB/Artikel fortschreibt. Die LIB wird in den Übergabeparametern des Triggers benannt.
Gravierender Vorteil:
Nur 1 Open, und der kann offen bleiben, und man bekommt nur tatsächlich vorhandene Sätze.
Bei 60 Dateien ist die Wahrscheinlichkeit, dass einige Open/Chain/Close vergebens sind, sehr hoch.