exec sql drop variable

[Robi]

Hi *all

habe hier in einem SQLRPGLE Pgm folgende Befehle

C/EXEC SQL     DROP TABLE QTEMP/KPI_ZV                 
C/END-EXEC                                             
C/EXEC SQL     DROP   VARIABLE LFNR2                   
C/END-EXEC                                             
C/EXEC SQL     DROP   VARIABLE RRTT2                   
C/END-EXEC                                             
C/EXEC SQL     DROP   VARIABLE RRMM2                   
C/END-EXEC                                             
C/EXEC SQL     DROP   VARIABLE RRJJ2                   
C/END-EXEC                                             
C/EXEC SQL     DROP   VARIABLE SQ_DATUM                
C/END-EXEC                                             
C/EXEC SQL     CREATE VARIABLE LFNR2 DECIMAL (2, 0)    
...

Wenn das Pgm läuft habe ich im Joblog eine Meldung, das die Datei KPI_ZV nicht gelöscht werden konnte, da Sie nicht existiert. --> OK
Die nächste Meldung im Joblog ist, das LFNR2 der Art *SRVPGM in QGPL bereits vorhanden ist.

Ich habe keine Erfolg/Mißerfolg Meldung für die DROP Variable ...

kann das jemand erklähren.

Danke Robi

[B.Hauser]

Hi *all

habe hier in einem SQLRPGLE Pgm folgende Befehle

C/EXEC SQL     DROP TABLE QTEMP/KPI_ZV                 
C/END-EXEC                                             
C/EXEC SQL     DROP   VARIABLE LFNR2                   
C/END-EXEC                                             
C/EXEC SQL     DROP   VARIABLE RRTT2                   
C/END-EXEC                                             
C/EXEC SQL     DROP   VARIABLE RRMM2                   
C/END-EXEC                                             
C/EXEC SQL     DROP   VARIABLE RRJJ2                   
C/END-EXEC                                             
C/EXEC SQL     DROP   VARIABLE SQ_DATUM                
C/END-EXEC                                             
C/EXEC SQL     CREATE VARIABLE LFNR2 DECIMAL (2, 0)    
...

Wenn das Pgm läuft habe ich im Joblog eine Meldung, das die Datei KPI_ZV nicht gelöscht werden konnte, da Sie nicht existiert. --> OK
Die nächste Meldung im Joblog ist, das LFNR2 der Art *SRVPGM in QGPL bereits vorhanden ist.

Ich habe keine Erfolg/Mißerfolg Meldung für die DROP Variable ...

kann das jemand erklähren.

Danke Robi

Wenn Du irgendwelche SQL Objekte ohne Bibliothek anlegst, werden diese bei Verwendung von System Naming in der Bibliothek QGPL erstellt.

Wenn Du unter System Naming mit DROP ein Objekt löschst, wird die Bibliotheksliste nach dem Objekt durchsucht.

In Deinem Fall könnte ich mir vorstellen, dass die globale Variable in der Bibliothek x, die vor der QGPL steht gelöscht wird, während in der QGPL die Variable existiert.

Warum willst Du überhaupt globale Variablen löschen. Die funktionieren wie Datenbereiche in der QTEMP, d.h. Du musst den Inhalt lediglich in jedem Job (über ein SET-Statement) initialisieren.

Birgitta

[Robi]

Moin Birgitta,

das PGM läuft täglich.
Wenn ich Systemweit suche, gibt es diese Variablen NUR in der QGPL.
Alle habe als Erstellungsdatum Monat 6/2012

Es wurde die Var also noch NIE gedropt (heist das so?)
Findet SQL keine Var zum droppen, erwarte ich eine MSG im Joblog, wie bei der fehlenden Datei.

Warum willst Du überhaupt globale Variablen löschen. Die funktionieren wie Datenbereiche in der QTEMP, d.h. Du musst den Inhalt lediglich in jedem Job (über ein SET-Statement) initialisieren.

Das geht nur in (wenigstens Einigermaßen) dokumentierten Systemen. Hier kann ich nicht garantieren, das nicht ein 'kopiertes Pgm' die Variable auch verwendet, (drop und set), aber als alpa und mit 50 Stellen.

Robi

[andreaspr@aon.at]

Eventuell ein Berechtigungsproblem?
lg Andreas

[Robi]

nein, leider nicht.
der Anwender hätte löschen dürfen!
(wenn nicht, hätte ich auch da eine MSG im Joblog erwartet)

Robi

[BenderD]

... ich frage mich jetzt gerade, wie ich bisher ohne sowas ausgekommen bin. Welches Problem wollt ihr damit lösen? oder wollt ihr euch nur ein weiteres schaffen?

D*B

[Robi]

@Dieter

ich brauche diese Felder, da im SQL
(Birgitta, verzeih mir die fehlenden Fachbegriffe)
in einer Abfrage mit

WITH a as ...

kein

where lfnr = :LFNR

möglich ist.

Und die findigen Kollegen probieren das natürlich gleich mal in Ihren Programmen aus.
Mir hat diese Idee von Birgitta damals SEHR!! geholfen diese riesigen SQL abfragen zum laufen zu bekommen.

und ja ... es hätte andere Wege gegeben ...
(z.B. ohne SQL )

(Es geht ja alles, mir ist heute nur das Joblog aufgefallen)

Robi

[BenderD]

@Dieter

ich brauche diese Felder, da im SQL
(Birgitta, verzeih mir die fehlenden Fachbegriffe)
in einer Abfrage mit

WITH a as ...

kein

where lfnr = :LFNR

möglich ist.

Und die findigen Kollegen probieren das natürlich gleich mal in Ihren Programmen aus.
Mir hat diese Idee von Birgitta damals SEHR!! geholfen diese riesigen SQL abfragen zum laufen zu bekommen.

und ja ... es hätte andere Wege gegeben ...
(z.B. ohne SQL )

(Es geht ja alles, mir ist heute nur das Joblog aufgefallen)

Robi

... du baust doch anschließend den CTE (dat Dingens bei dem with) in ein select ein, da kann man doch dann die where Klausel entsprechend erweitern, oder hast du mal ein Beispiel, wo das nicht geht?

Dieter

[B.Hauser]

Wenn ich mich recht erinnere hatte ich die Globalen Variablen damals in Rekursiven CTEs, die ich in Views hinterlegt hatte verwendet, um den Anfangspunkt zu setzen.

Birgitta

[BenderD]

Wenn ich mich recht erinnere hatte ich die Globalen Variablen damals in Rekursiven CTEs, die ich in Views hinterlegt hatte verwendet, um den Anfangspunkt zu setzen.

Birgitta

... wie belegt man das dann in einer View mit einem variablen Wert, den man nicht anderweitig genauso zur Verfügung hat?

D*B

[B.Hauser]

Globale SQL-Variablen funktionieren ähnlich wie Datenbereiche in der QTEMP auch wenn die Variable als permanentes Objekt in einer beliebigen Bibliothek gespeichert ist. Der Wert der Variablen wird innerhalb des Jobs vor Aufruf/Ausführung der View gesetzt, einfach mit dem SQL Statement SET. Die globale Variable selber wird in der View-Definition angegeben (wie andere Spalten, Special Registers oder konstante Werte). Die globale Variable muss allerdings vor Erstellung der View generiert sein.

In mehreren Jobs kann die gleiche (globale) Variable unterschieldiche Werte haben.
Beispiel: Stücklisten-Auflösung. In Job1 wird die Artikel-Nr. 4711 analysiert, während im zweiten Job die Artikel-Nr. 5713 verwendet wird.

Job1:

Set ArtikelNr = '4711';
Select * from View;

Job2:

Set ArtikelNr = 5713';
Select * From View

Birgitta

[BenderD]

Globale SQL-Variablen funktionieren ähnlich wie Datenbereiche in der QTEMP auch wenn die Variable als permanentes Objekt in einer beliebigen Bibliothek gespeichert ist. Der Wert der Variablen wird innerhalb des Jobs vor Aufruf/Ausführung der View gesetzt, einfach mit dem SQL Statement SET. Die globale Variable selber wird in der View-Definition angegeben (wie andere Spalten, Special Registers oder konstante Werte). Die globale Variable muss allerdings vor Erstellung der View generiert sein.

In mehreren Jobs kann die gleiche (globale) Variable unterschieldiche Werte haben.
Beispiel: Stücklisten-Auflösung. In Job1 wird die Artikel-Nr. 4711 analysiert, während im zweiten Job die Artikel-Nr. 5713 verwendet wird.

Job1:

Set ArtikelNr = '4711';
Select * from View;

Job2:

Set ArtikelNr = 5713';
Select * From View

Birgitta

... das ist doch wieder so ein "just to fool the russians" Feature nach dem Motto: Zaubertuch in den Hut, Kaninchen raus. (Was passiert da eigentlich, wenn man noch kein Set gemacht hat, geht es dann ab in den Wald?) Und ich sehe die View immer noch nicht, für die man sowas braucht - und zur Parametrisierung gibt es ja auch noch UDTFs, bei denen man einen klaren Zusammenhang zwischen reingehenden Werten und rauskommenden Daten sieht. Naja, Spielzeug, für Leute, die zuviel Zeit haben (denen ich weiterhin viel Spass wünsche)...

D*B