exec sql drop variable

[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

[B.Hauser]

Was passiert da eigentlich, wenn man noch kein Set gemacht hat, geht es dann ab in den Wald?

Man kann natürlich einen Default-Wert bei der Variablen-Definition vorgeben.

Birgitta

[Fuerchau]

Da entzieht sich mir auch der Sinn einer globalen Variable, wenn sie denn doch jobspezifisch ist und somit eine lokale Varibale ist.

[BenderD]

Da entzieht sich mir auch der Sinn einer globalen Variable, wenn sie denn doch jobspezifisch ist und somit eine lokale Varibale ist.

... die ist Connection spezifisch, sprich ACTGRP level und dass man eine lokale Variable global nennt und den Typ global festlegt, aber lokal verwendet, erhöht den Verwirrungsfaktor, das hat richtig Potential - und ich sehe einige Gesichter vor mir, die das ausloten werden (nach dem Motto: ich habe hier eine Lösung und suche das passende Problem), oder bereits tun...

D*B

[B.Hauser]

War es vielleicht besser, dass man das Ding LOCAL Data Area (*LDA) genannt hat, jedoch den Inhalt GLOBAL (programmunabhängig) für den ganzen Job verwendet hat??????

In diesem Fall finde ich GLOBAL für den ganzen Job im Gegensatz zu LOKAL (programm-intern) fast logischer!

... vielleicht solltet Ihr Euch bei der IBM oder auch bei denjenigen, die den SQL Standard definieren beschweren. Die haben nämlich diese Namensgebung verbrochen!

Birgitta

[BenderD]

War es vielleicht besser, dass man das Ding LOCAL Data Area (*LDA) genannt hat, jedoch den Inhalt GLOBAL (programmunabhängig) für den ganzen Job verwendet hat??????

In diesem Fall finde ich GLOBAL für den ganzen Job im Gegensatz zu LOKAL (programm-intern) fast logischer!

... vielleicht solltet Ihr Euch bei der IBM oder auch bei denjenigen, die den SQL Standard definieren beschweren. Die haben nämlich diese Namensgebung verbrochen!

Birgitta

... das ist doch mal ein treffender Vergleich LDA mit create variable, das hat beides Potential für Murks!
Ob ich mich da über den SQL Standard beschweren muss? ich meine eher nicht, das ist m. E. keiner. Gefunden habe ich das nur bei SQL Anywhere und die definieren das Ding auch auf Connection Level und schmeißen das anschließend weg - und das scheint ja bei der 400 anders zu sein.
Meine Empfehlung ist klar und eindeutig: Finger weg von unnötigen Gimmicks - und ich habe sowas noch nicht vermisst und sehe auch momentan kein Beispiel, wo das einen realen Vorteil hat. Guter Programmierstil zeichnet sich oft dadurch aus nur das zu benutzen, was man braucht und nicht dadurch so viel wie möglich von dem zu verwenden, was es da so alles gibt.

D*B