RUNQRY mit Variablen

[zannaleer]

Hallo Forum,

ich habe ein Query, das ich einmal im Monat für einen Anwender aufrufen muss. Vorher müssen aber 2 Werte der Abfrage geändert werden. Da ich als Programmierer von berufswegen faul bin, möchte ich dem Anwender das Query so zur Verfügung stellen, dass er nur diese beiden Werte eingeben kann und das Query dann ausgeführt wird.
Hat eine(r) von Euch den entscheidenden Tipp?

Danke und Gruß
Alexander

[Fuerchau]

Mit RUNQRY ist das nicht möglich.
Du kannst nur per QM-Qry und STRQMQRY Parameter übergeben.

[BenderD]

Hallo,

zu ergänzen sei noch, dass man bei STRQMQRY ALWQRYDFN(*YES) angeben kann und dann auch 400er Queries mit Parametern aufgerufen werden können. In dem Query nimmt man dann Referenz auf Hostvariablen (:meineVar), behauptet dann, dass diese aus einer Datei stammen und gibt selbiger einen Namen (Dummy oder Aetsch). Was damit nicht gut geht, sind Print Ausgaben.
Was sind das denn für Variablen, wenn das nämlich Datum bezogene sind, dann geht das meist auch mit current(date) und ein wenig Daten Gefrickel.

mfg

Dieter Bender

Mit RUNQRY ist das nicht möglich.
Du kannst nur per QM-Qry und STRQMQRY Parameter übergeben.

[Fuerchau]

Aber Vorsicht bei "STRQMQRY ALWQRYDFN(*YES)".
Auf Grund der möglichen Verknüpfungen von Dateien stellt sich das Ergebnis von Query und QM-Query mitunter anders dar, da Query wohl nicht unbedingt SQL verwendet.

[Pikachu]

Probiere mal den Parameter RCDSLT(*YES) beim Befehl RUNQRY.

[BenderD]

Hallo,

was hast du da im Auge??? mir ist da nix bekannt.

mfg

Dieter Bender

Aber Vorsicht bei "STRQMQRY ALWQRYDFN(*YES)".
Auf Grund der möglichen Verknüpfungen von Dateien stellt sich das Ergebnis von Query und QM-Query mitunter anders dar, da Query wohl nicht unbedingt SQL verwendet.

[Fuerchau]

@Dieter
Verknüpfung 1:
entspricht eigentlich einem Left-Join, mit der SQL-Umsetzung wird aber leider ein Inner-Join daraus, da die Verknüpfung grundsätzlich als Where-Klausel und nicht als Join-Klausel übersetzt wird (RTVQMQRY ALWQRYDFN(*YES)).

Das kannst du nur auflösen, wenn du die SQL-Quelle nochmal manuell bearbeitest.

Betrifft meines Wissenas auch Verküpfung 3, einzig Verknüpfung 2 ist korrekt, da es egal ist ob der Join im where oder join...on steckt.

[BenderD]

Hallo Baldur,

ein RTVQMQRY ist nicht erforderlich!!! Der STRQMQRY hat selber einen Parameter ALWQRYDFN.

mfg

Dieter Bender

@Dieter
Verknüpfung 1:
entspricht eigentlich einem Left-Join, mit der SQL-Umsetzung wird aber leider ein Inner-Join daraus, da die Verknüpfung grundsätzlich als Where-Klausel und nicht als Join-Klausel übersetzt wird (RTVQMQRY ALWQRYDFN(*YES)).

Das kannst du nur auflösen, wenn du die SQL-Quelle nochmal manuell bearbeitest.

Betrifft meines Wissenas auch Verküpfung 3, einzig Verknüpfung 2 ist korrekt, da es egal ist ob der Join im where oder join...on steckt.

[Fuerchau]

@Dieter
Das ist mir bekannt. Ich wollte nur darauf hinweisen, dass ALWQRYDFN eben intern ja erst ein RTVQMQRY durchführt und eben dann Join's nicht wie erwartet funktionieren !

[BenderD]

Hallo,

ich hatte eigentlich gehofft, die hätten das mittlerweile hingekriegt...
da bleibt dann nur noch anzqry und hoffen, dass das wenigstens stimmt, oder die Parameter Datei mit einem Satz, die man zu joint (Freud'scher Vertipper) ohne where Bedingung; selbige kann man sich dann ja mit einem parametrisierten Query erstellen, dann brauchts ein CL mit 2 Qry Aufrufen; dann ist auch die Print Problematik mit erschlagen.

mfg

Dieter Bender

@Dieter
Das ist mir bekannt. Ich wollte nur darauf hinweisen, dass ALWQRYDFN eben intern ja erst ein RTVQMQRY durchführt und eben dann Join's nicht wie erwartet funktionieren !

[Fuerchau]

Naja, ich helfe mir dann sowieso immer mit 2 (oder auch mehr) Queries:

1. STRQMQRY mit Parametern in OUTFILE
2. RUNQRY aus OUTFILE wegen Formatierung.

Manchmal ist es auch sinnvoll eine temporäre View zu erstellen (über QMQRY per Create View), da bestimmte Query-Mimiken (Gruppenwechsel, nur Summenzeilen o.ä.) sonst nicht funktionieren.