SQLRPGLE kein Update nach Umstellung auf V7R1

[lucullus]

Moin, moin,

den (Fehler)hinweis gabs schon immer; hatte aber keine negativen Auswirkungen.

Ich werde die Programme ändern und dann kurzes Statement geben.

Danke für den Hinweis!

Andreas

[Fuerchau]

Vielleicht gibts da ja eine Option zum automatischen abschneiden (kenne ich allerdings nicht).
Die andere Variante ist ggf. die, dass das Abschneiden von Leerzeichen ja nur als Warnung ausgegeben wird, da dies unkritisch ist (außer bei VARLEN-Feldern).
Aber vielleicht ist die nun zu speichernde Information nun auch nach dem Abschneiden der Leerzeichen immer noch zu lang.

[B.Hauser]

Mich würde trotz allem der SQLCODE nach dem Update interessieren. Dann könnte man genaueres zu der Ursache sagen.

Birgitta

[Obv]

leerzeichen abschneiden sollte kein problem sein und auch keine fehlermeldung hervorrufen.
Die Fehlermeldung klingt eher als wäre der tatsächliche Inhalt zu lang!
Das Update wird dann auch nicht ausgeführt

eine lösung:

dfname = substr (:p0ktbz, 1, length (dfname))

commit sollte natürlich auf *NONE sein

[Fuerchau]

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 .

[lucullus]

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]

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