exec sql drop variable

[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

[andreaspr@aon.at]

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.

Das gleiche habe ich auch schon von SQL gehört
Das Phänomen, dass man neuem eher Kritisch gegenüber steht ist ja nichts neues.
Vielleicht sagen die Menschen in 10 Jahren: Wieso hat man(n) damals so kompliziert gearbeitet, wenn es doch einfachere Ansätze gibt. (u.a. auch Sequenzen)

Allerdings muss ich zugeben, dass ich bis jetzt auch noch keinen Einsatz für die globale Variable finden konnte.
Detto mit LDAs. Wobei ich lieber die SQL Variable verwenden würde als eine LDA.

Eventuell für Webanwendungen wo für eine Verarbeitung die Session-ID mehrere Programme/Prozeduren benötigen.
Die könnte dann in der globalen Variable gespeichert werden.

Vielleicht findet sich ja noch ein konkretes Beispiel wo es durchaus Sinn macht!

lg Andreas

[Robi]

das Ursprüngliche Problem war:
http://newsolutions.de/forum-systemi...-lib-file.html

Dank Birgitta konnte ich es lösen.

Da hier im Forum immer mal wieder Probleme gelöst werden, die wir noch nie hatten ...
finde ich die Diskusion recht amüsant.

Aber ich bin sicher Dieter hat recht.
1. nicht alles was geht muß man auch machen.
2. es gibt immer eine andere Lösung.

Wenn der drop Variable mit erzählen würde, warum er nicht geht, gäbe die Diskusion nicht.

Robi

[B.Hauser]

Wenn der drop Variable mit erzählen würde, warum er nicht geht, gäbe die Diskusion nicht.
Robi

Habt Ihr's mal damit versucht im Programm den SQLCODE zu prüfen und anschließend mit GET DIAGNOSTICS euch den Fehler-Text zu holen ?

Oder einen STRDBG (ohne alle Parameter) vor der Programm-Ausführung abzusetzen und das Joblog danach zu prüfen?

Birgitta

[Fuerchau]

Ich denke mal, da die Variable letztendlich lokal ist (Job) hat eben drop variable keinen Effekt auf das Objekt selber. Dies dient nur der Typdefinition der Variable, was man eigentlich durch einen UDT auch lösen kann.

In SQL gibt es (je nach Datenbank) halt noch den Begriff "Session Variable", was der Verwendung wohl näher kommt.
Zumal diese dann nach Close Connection auch wieder weg ist.
Auch gibt es Variablen für die aktuelle Transaktion, die dann nach Commit/Rollbback auch wieder weg sind.

Im Sinne von Global scheint mir das aber doch eher für die ACTGRP zu gelten. Schließlich kann ich ja je ACTGRP eigene Verbindungen zur DB aufnehmen und jeweils separat die Variable verwenden.
Nicht auszudenken, welche Verwirrungen es gibt (siehe Dieter), wenn eine ACTGRP die Variable einer anderen ACTGRP überschreibt.

Stelle ich dann meine Software auf ODBC/JDBC um habe ich ja je Verbindung auch noch einen eigenen Job, so dass ich mich nun auf obige Verwirrung auch noch nicht mal verlassen kann.

[BenderD]

Nicht auszudenken, welche Verwirrungen es gibt (siehe Dieter), wenn eine ACTGRP die Variable einer anderen ACTGRP überschreibt.

Das kann nicht passieren, da das ja gerade Connection bezogen ist. Was da rein technisch im Hintergrund passiert (Generierung eines Serviceprogramms) ist zwar abenteuerlich, aber isoliert auch betreffs unterschiedlicher Typen die Sessions untereinander und interessiert mich im Grunde wenig.

Variablen gibt es auch in SQL PL (procedure language) und diese haben immer den scope innerhalb der Procedure; die mit create variablen haben darüber hinausgehende Sichtbarkeit, das ist eher das Pendant zum Export von Variablen im ILE und in diesem Sinne erklärt sich auch der Name global - mißverständlich ist in erster Linie die Formulierung in der SQL Reference: "The CREATE VARIABLE statement defines a global variable at the application server."

Ich habe inhaltlich zwei Einwände:
- Variablen gehören nicht exportiert, weil ein anderer Prozess im callstack den Inhalt einer solchen Variablen unkontrollierbar korrumpieren kann.
- die Mimik in mixed Environment angewandt macht die Tür auf in ein RPG Programm sowas wie eine SQL Procedure schrittweise einzubetten und dass sowas schief geht, hat man schon mit Scriptlets in JSPs und Javascript und auch PHP zur genüge ausprobiert.

Sollte mir doch noch jemand ein Beispiel liefern, wo man das braucht, dann kann man das ja konstruktiv weiterentwickeln.

D*B

[andreaspr@aon.at]

Zu beachten ist auch dass globale Variablen von Commitment Control ausgeschlossen sind!
Nach einem Commit oder Rollback steht in der Variable noch der gleiche Wert wie zuvor.

[Fuerchau]

Nun, das ist ja auch mit dem Begriff Global, besser Session/Connection, eindeutig gesagt.