View Full Version : SQLRPGLE kein Update nach Umstellung auf V7R1
Das mit dem commit hätte ich nicht erwähnt. Dies liegt in der Art der Anwendung ob Commit=*none oder commit <> *none nötig ist.
PS:
Und sich auf die Art der Fehlerbehandlung zu verlassen, dass diese mit dem nächsten Release auch noch gilt, ist sträflicher Leichtsinn.
Hättest du dich bei V6 (oder früher) schon darum gekümmert hättest du die Probleme jetzt nicht :).
Moin, moin,
so vielen Dank für die vielen Antworten, Anregungen und erhobenen Zeigefinger.:o
Das Problem ist mit der Beseitung des Feldlängenfehlers behoben.
Der SQLCOD war -404
Ich/wir geloben Besserung bei Achtung von Warnhinweisen.:D
Nochmals Danke an alle.
Andreas
Hallo Andreas,
nur zur Information:
1. SQLCODE -404 = Wert für Spalte oder Variable &1 zu lang.
Den Fehlertext kann man relativ leicht in der Message-Datei QSQLMSG nachschauen. SQLCODE -404 --> Message Id SQL404. Die variablen Message-Texte (&1) werden im Feld SQLER3 ausgegeben.
2. Seit Release V5R3 kann der Message-Text auch relativ einfach im RPG-Programm ermittelt werden:
EXEC SQL ..... ;
If SQLCODE < *Zeros; //Fehler
Exec SQL Get Diagnostics Condition 1 :MsgText = MESSAGE_TEXT;
//Anzeige / Verarbeitung
EndIf;
... auf alle Fälle sollte der SQLCODE IMMER nach einem SQL-Statement geprüft werden.
Birgitta
... das ging aber vorher auch schon schief, dass in 20 Byte keine 50 reinpassen hat sich doch mit dem Release nicht geändert und da kam auch derselbe SQL-Köter zurück und hat den Programmierer gebissen...
D*B
Moin, moin,
so vielen Dank für die vielen Antworten, Anregungen und erhobenen Zeigefinger.:o
Das Problem ist mit der Beseitung des Feldlängenfehlers behoben.
Der SQLCOD war -404
Ich/wir geloben Besserung bei Achtung von Warnhinweisen.:D
Nochmals Danke an alle.
Andreas
... das ging aber vorher auch schon schief, dass in 20 Byte keine 50 reinpassen hat sich doch mit dem Release nicht geändert und da kam auch derselbe SQL-Köter zurück und hat den Programmierer gebissen...
D*B
... unsauber war es allemal!
Aber IBM hat in den letzten Releasen bei einigen Unsauberkeiten, die vorher toleriert bzw. nicht geprüft wurden, das Error Level angehoben, d.h. anstatt einer Warnung (positiver SQLCODE) wird ein Fehler ausgegeben.
Beispiel: Lokale Definition von Host Variablen. Unter Release V5R2 konnte die gleiche Variable in problemlos mehreren Prozeduren lokal definiert und in SQL-Statements verwendet werden. Mit Release V5R3 wurde in solchen Situationen bei der Compilierung Error Level 30 ausgegeben.
Birgitta
Speziell zu letzterem haben es sich die SQL-Precompilerentwickler zu einfach gemacht, denn lokale Variablen sind nun mal lokal und werden durch die SQL-Auflösung, also die generierten RPG-Anweisungen, nicht global.
Statt also den Errorlevel anzuheben hätten die sich eher Gedanken über die Erkennung von globalen und lokalen Variablen machen müssen.
Speziell zu letzterem haben es sich die SQL-Precompilerentwickler zu einfach gemacht, denn lokale Variablen sind nun mal lokal und werden durch die SQL-Auflösung, also die generierten RPG-Anweisungen, nicht global.
Statt also den Errorlevel anzuheben hätten die sich eher Gedanken über die Erkennung von globalen und lokalen Variablen machen müssen.
Ist ja inzwischen behoben!
In V5R4 konnten gleiche Variablen (gleiche Definition) bereits problemlos lokal definiert und verwendet werden. Nur mit abweichender Definition (z.B. LocText als 256A varying und LocText als 50C) gab es Probleme.
Seit Release 6.1 können lokale Variablen auch abweichend definiert werden und in embedded SQL verwendet werden.
... übrigens die Antwort, die ich damals von IBM erhalten habe war, dass durchaus dokumentiert war, dass eine Host-Variable nur einmalig innerhalb einer Quelle definiert werden sollte (was auch stimmte!). IBM hatte es jedoch vor V5R3 nicht geprüft und die erste Definition genommen, die sie gefunden hatten.
Birgitta
andreaspr@aon.at
08-02-13, 09:23
@Birgitta: Wie immer sehr kompetent und vor allem informativ!
Man merkt, dass du einen guten und direkt Draht zur IBM hast :)
Deine insider Infos sind eine gute Ergänzung zum Infocenter ;)
lg Andreas