Umwandlungsfehler SQL0312 Variable ... nicht definiert oder ...

[harkne]

Hallo zusammen,

ich habe folgendes Problem.
Bei der Umwandlung erhalte ich immer den nachfolgenden Fehler

                                             DIAGNOSENACHRICHTEN              MSG ID  WTK  SATZ  TEXT                                                       SQL0312  30      78  Position 43 Variable IOBJN nicht definiert oder aufgrund                      von Ursachencode 1 nicht verwendbar.                                         Nachrichtenzusammenfassung                                  Gesamt    Info   Warnung      Fehler  Wertigk. Beendigung                         1        0         0          0        1         0                      Fehler der Wertigkeitsstufe 30 in Quelle gefunden.                              125 Quellensätze verarbeitet. 

Ich kann die Quelle leider nicht posten, wegen der Formatierung.

Nachfolgend die entscheidenden Dinge

dcl-s iObjLib char(10);

exec sql declare curdev cursor for

SELECT
cast(OBJNAME as char(10)), cast(OBJLIB as char(10)),cast(OBJCREATED as TIMESTAMP),
cast(LAST_00001 as TIMESTAMP)
from
TABLE(QSYS2.OBJECT_STATISTICS ('*ALL','DEVD'))
WHERE
(
add_years(last_used_timestamp, +2) < current_date
or (last_used_timestamp is null and add_years(OBJCREATED, +2) < current_date)
)
and objattribute = 'DSPVRT';



exec sql open curdev;


// fetch next, nächsten Satz innerhalb des recordsets lesen
exec sql fetch next from curdev into :iObjN,
:iObjLib,
:iObjCreated,
:iLastUsed;

[B.Hauser]

Wie ist denn iObjN definiert. Die zugehörigen D-Bestimmungen sind nicht zu sehen ... und der SQL-Fehler bezieht sich auf diese Variable

[Fuerchau]

Du deklarierst iObjLib, verwendest aber IOBJN ?

[harkne]

Du deklarierst iObjLib, verwendest aber IOBJN ?

OK, bitte das Thema vergessen.

Nein, ich habe nur den falschen DCL-S gepostet.
Die Variable ist schon richtig definiert, aber ich hatte bei ctl-opt vergessen am Ende das ; anzugeben und der erste DCL-S ist das Feld iObjN und deshalb hat er das bei der Umwandlung nicht erkannt.

Ich habe mit Visual Studio Code begonnen und weiß noch nicht wie man die Syntaxprüfung aktivieren kann. Deshalb hat er mir ohne das ; keinen Fehler angezeigt. Und der SQL-Precompiler bringt dann den angegebenen Fehler.

Trotzdem vielen Dank

ctl-opt dftactgrp(*no) actgrp(*caller) bnddir(system/#allfunc);
// ================================================== ================
// Prototypen
// ================================================== ================
// /COPY syssrc/qfuncpysrc,#allfuncfr
// ================================================== ================
// Definition interner Variablen
// ================================================== ================
dcl-s iObjN char(10);
dcl-s iObjLib char(10);
dcl-s iObjCreated timestamp;

[AG1965_2]

Es gibt meines Wissens nach (noch) keine Syntaxprüfung, mit Ausnahme der DB2 for i-Erweiterung.
Aber man kann relativ flott compilieren und mit dem *EVENTF kann man die Fehler dann im Sourcefile selber sehen und/oder sich auch die Spool-Datei gleichzeitig anzeigen lassen.
Und in **FREE hilft einem nicht nur VS Code mehr, auch der Linter kann zuschlagen und der hilft dann wirklich während des Editierens, derartige triviale Fehler zu vermeiden.

[Fuerchau]

Es gibt sogar "triviale" Fehler, die auch bei bester Syntaxprüfung nicht feststellbar sind.
Seit V7... wird jede Spalte, die nicht einer Tabelle zugeordnet werden kann, als globale SQL-Variable festgelegt.
Merken tut man das nur zur Laufzeit, da der SQL mit negativem SQL-Code (globale Variable nicht deklariert) zurückkommt.
Ich habe es mir daher angewöhnt, den ggf. generierten SQL-Spool auch bei korrekter Umwandlung genauer zu untersuchen.
Globale Variablen werden mit Fehlerbewertung 10 ausgewiesen, was nicht zum Abbruch der Umwandlung führt. Auf solche Dinge muss man ebenso achten.

Auch ein generelles Problem sind die praktischen "global tamporary table" (GTT), die einfach deklariert werden und in der QTEMP automatisch erstellt werden.
Allerdings Vorsicht bei der Verwendung von Transaktionen:
- GTT werden nicht journalisiert
- Commit / Rollback löschen den Inhalt einer GTT (warum auch immer)
Also alle Insert/Update/Delete auf GTT müssen immer mit "with nc" ergänzt werden, sonst klappts nicht.
Ich habe nicht näher untersucht, warum das so ist.

Zusätzlich wirft der SQL-Precompiler jede Menge 10-Warnungen bei der Verwendung von GTT aus, da er weder die Tabelle noch die Spalten findet.
Er stellt also keinen Zusammenhang zwischen einem "Declare GTT" und die Anwendungen der GTT her.
Also auch hier muss man prüfen, welche Variablen da nicht gefunden wurden, es könnte auch nur ein Tippfehler sein.

[AG1965_2]

Achja, und was mir auch noch aufgefallen ist:
Es wird hier beim Löschen lange unbenutzter virtueller Devices nicht wirklich drauf ankommen, aber trotzdem:
Du lässt die arme Maschine zu jedem Timestamp in der Datei 2 Jahre dazu rechnen - wäre es nicht schneller, wenn Du vom aktuellen Timestamp 2 Jahre abziehst und mit dem Timestamp vergleichst?
Und COALESCE(Wert1, Wert2, ..., Wertn) liefert aus der Werte-Liste den ersten zurück, der nicht NULL ist.
Ich würde da einfach schreiben:

where coalesce(last_used_timestamp, objcreated) < current date - 2 years ... 

Denn so schlau wird der Optimierer wohl nicht sein.
Oder doch, liebe Birgitta Hauser?

[Fuerchau]

Jede Funktion auf eine Spalte im Vergleich verhindert die Nutzung eines Index.
Außerdem, wenn die 1. Variable nicht NULL ist, wird sie sowieso immer genommen und du kannst den Coalesce sparen.
Für Indexnutzung ist die separate Schreibweise besser.