Eingabebibliothek im Query ändern / V5R2

[Erni]

Hallo,



hat jemand einen Tipp oder ein Tool, wie man die Eingabebibliothek

in mehreren Query's ändern kann, ohne diese einzeln aufzurufen ?



Problem:



Unsere ERP-Software wird demnächst unter einem anderen Bibliotheksnamen

zu finden sein. Seither haben ca. 4500 Query’s mit ca. 9000 Dateiangaben auf

die alte Bibliothek zugegriffen. Nun sollte der Zugriff natürlich auf die neue

Bibliothek erfolgen.



Vielleicht hat ja jemand eine Idee, wie man das auch für die Zukunft abhandeln

kann.



Danke und Gruß

Jochen

[Fuerchau]

Tja, da ist wohl Handarbeit gefragt.

Es gibt da nur ein Tool, dass die verwendeten Dateien eines Queries auslesen kann, aber eine Änderung ist leider nicht möglich.
Vielleicht kann man dann ja ggf. OVRDBF's machen, was aber trotzdem Handarbeit bedeutet, da ja die meisten Queries aus WRKQRY aufgerufen werden.

[Fuerchau]

PS:
Beim Query hat mich schon immer gestört, dass die LIB nicht über *LIBL gesucht werden kann.

[mk]

Hallo Jochen,

es kommt darauf an wie deine Queries gestartet werden.

So wie ich es verstanden habe wird sich der Name deiner Datenlibrary ändern.

Wenn deine Queries über den Befehl RUNQRY
gestartet werden kannst Du global für den Job
ein OVRDBF auf die neue Bibliothek machen.

Der Runqry verwendet die Datei aus dem Override.

Wenn deine User aber über WRKQRY arbeiten
musst Du jede Querydefinition anpassen.

Gruss Michael

[Fuerchau]

Im RUNQRY kann die zu verwendende Datei/Bibliothek direkt angegeben werden QRYFILE((LIB/F1) (LIB/F2)....), was natürlich etwas aufwändig wäre.

Vielleicht bin ich ja bereit, auf Basis des Programmes RTVQRYF (MI-Programm) ein CHGQRYLIB zu entwickeln.
Wer ist bereit dafür etwas Geld auszugeben ?

[Frank Ziegler]

Hallo,

a propos RunQry: wie wär's mit
RunQry ((*LIBL/F1) (*LIBL/F2) ... )
in einem Menü ?
Wenn man mit mehreren Datenbibliotheken in mehreren Umgebungen arbeitet, z.Bsp. PRODUCTION/TEST, ist das ohnehin die Lösung.

Gruss F.Ziegler

[RobertMack]

@Fuerchau

Der Hammer wäre ein Tool, das solche Altlasten (Queries) in SQLRPGLE übersetzt ;-)

Grüße,
Robert

[Fuerchau]

@Robert

Dafür brauchts kein Tool. RTVQMQRY reicht da vollkommen aus, da dieser auch *QRYDFN-Objekte zuläßt.
Den SQL hast du dann anschließend in einer SRCPF.

[Pikachu]

Hallo Fürchau !

RTVQMQRY reicht da vollkommen aus, da dieser auch *QRYDFN-Objekte zuläßt. Den SQL hast du dann anschließend in einer SRCPF.

Dieser SQL stimmt meines Wissens nach aber nicht unbedingt mit dem Query überein. Zum Beispiel besteht dieser SQL nur aus INNER JOINs, auch wenn in der Query bei "Art der Verknüpfung" Auswahl "2=Mit Primärdatei gleiche Sätze" ausgewählt wurde. Der SQL liefert also u.U. auch weniger Datensätze als die Query.

Viele Grüße
Jürgen

[Fuerchau]

Auswahl "2=Mit Primärdatei gleiche Sätze" ist ein INNER JOIN !

[Pikachu]

Hallo Fürchau !

Ich dachte, Auswahl "1=Gleiche Sätze" wäre ein INNER JOIN und Auswahl "2=Mit Primärdatei gleiche Sätze" ein OUTER JOIN. D.h. bei Auswahl 2 bekommt man auch die Datensätze der Primärdatei, zu denen kein passender Datensatz in den Sekundärdateien vorhanden ist (und obwohl die entsprechenden Verknüpfungsfelder angegeben sind). Das geht im SQL mit dem WHERE, das der RTVQMQRY ALWQRYDFN(*ONLY) daraus macht, leider nicht.

Viele Grüße
Jürgen

[RobertPic]

Auswahl "2=Mit Primärdatei gleiche Sätze" ist ein INNER JOIN !

Einspruch!!

Verknüpfungsart 1 (=gleiche Sätze):
ist ein INNER JOIN

Verknüpfungsart 2 (= mit Primärdatei gleiche Sätze)
ist ein LEFT OUTER JOIN

Verknüpfungsart 3 (= mit Primärdatei ungleiche Sätze)
ist ein OUTER JOIN

Ich kenne das Tool zwar nicht, aber wenn es die Verknüpfungsart 2 nicht mit LEFT OUTER JOIN übersetzt, ist es keine 100% Umsetzung.

Abgesehen davon, werden im SQL Felder von erfolglosen LEFT OUTER Joins mit NULL zurückgegeben, im Query mit dem Defaultwert. D.h. das ev. Abfragen anders reagieren können und 2. das Schlüsselwort VALUE (= COALESCE) im Query für diese Fälle unbrauchbar ist.

LG

Robert