SQLRPGLE kein Update nach Umstellung auf V7R1

[B.Hauser]

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

[BenderD]

... 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.

Das Problem ist mit der Beseitung des Feldlängenfehlers behoben.

Der SQLCOD war -404

Ich/wir geloben Besserung bei Achtung von Warnhinweisen.

Nochmals Danke an alle.

Andreas

[B.Hauser]

... 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

[Fuerchau]

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.

[B.Hauser]

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]

@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