QDBCRTHA + QDBRUNHA API's

[Fuerchau]

Diese API's dienen nur einem schnelleren Zugriff mittels HASH-Methoden an Stelle von normalen Indizees und dienen bestimmt nicht deinen Anforderungen.

Was willst du überhaupt erreichen ?
Mit variablen Dateien/Bibliotheken bietet sich da eher dynamisches SQL an.

[Winnilein]

In 60 Bibliotheken(je Filiale eine) liegt jeweils ein Bestandsdatei.
Keyfeld ist die Artikelnummer. Nun möchte ich in einem Programm
nach Eingabe der Artikelnummer die Bestände der einzelnen Filialen
in einem Subfile anzeigen und der kummuluierten Bestand in einem seperaten Feld.
Der Vorläufer dieses Programmes, der leider nicht die aktuellen Daten, sondern nur die Eingefrohrenen Daten des Vortages anzeigt(So ein Blödsinn!!) wir zur Zeit etwa 20000!!! Mal aufgerufen.
Wie bereits beschrieben ist die Methode mit OVRDBF im Programm sehr Recourcenfressend. Mein Test mit einem SQLRPGLE-Programm brachte auch keine Vorteile.

[Fuerchau]

Wenn die Daten sowieso statisch sind, kopiere diese doch alle in eine Datei mit Key Filiale/Artikel.
Auch das lässt sich automatisieren, da mittels DSPOBJD in Outfile alle Dateien ermittelbar sind und einfach ein CPYF in eine neue Bestandsdatei zusammenzuführen sind.

Ansonsten kann ich nur sagen: sch... Konzept der DB.

[Winnilein]

1. Sind die Daten nicht statisch.

2. Waren das bis vor einem Jahr 60! einzelne AS/400.

3. Würde ich ja gern die 60 Bestandsdateien in eine einzige zusammenführen, ist aber leider zur Zeut nicht möglich.

[Pikachu]

Hallo!

Du könntest versuchen, mehrere physische Dateien mittels einer logischen Datei zusammenzufassen.

Viele Grüße
Jürgen

[Winnilein]

Geht nicht, die Dateien haben leider alle den gleichen Satzformatnamen.

[Fuerchau]

Die Anzahl der LF's bzw. UNION-Selects sind leider beschränkt (ich glaube so um die 32, was bei V5R3 etwas erweitert wurde).
Eine Multi-Format-LF geht da auch nicht, da auch hier nur 32 Dateien erlaubt sind.

Es bleibt also nur die Tipparbeit tatsächlich 60 Selects zu kodieren, da damit ja die Lib qualifiziert angegeben werden kann:
select f1, f2, ... into :myf1, :myf2, ... from mylib/myfile where artikel=:myartikel
Ein Cursor ist da nicht erforderlich, da ja max. nur 1 Satz gelesen wird.

[Pikachu]

Hallo!

Eine Möglichkeit wäre vielleicht noch, mittels CPYF mit Feldtest (Parameter INCREL, alphanumerischer Vergleich) die jeweiligen Datensätze nach Eingabe der Artikelnummer aus den physischen Dateien in eine einzige physische Arbeitsdatei zu kopieren. In dieser Datei wären dann nur die entsprechenden Datensätze des ausgewählten Artikels vorhanden.

Viele Grüße
Jürgen

[Fuerchau]

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]

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.

[Fuerchau]

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.

[Pikachu]

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