SQLRPGLE kein Update nach Umstellung auf V7R1

[lucullus]

Moin, moin,

nach der der Umstellung von V6R1 auf V7R1 zeigen sich Probleme mit einigen SQLRPGLE-Programmen. Schreiben funktioniert nach wie vor, aber beim Update -> passiert nichts, auch keine Fehlermeldung.

Hier der Code:

     C/EXEC SQL
     c+ update DFERBUN
     c+      set dfstat = :erstat, dflock = :erlock,
     c+          dffa = :erfa,
     c+          dfkto = :##kton, dfname = :p0ktbz,
     c+          dfktkr = :erktkr, dfbr = :erbr,
     c+          dferdm = :ererdm, dfsh = :ersh,
     c+          dfefeu = :erefeu, dfwg = :erwg,
     c+          dfkurs = :erkurs, dfefku = :erefku,
     c+          dfwgeh = :erwgeh, dflern = :erlern,
     c+          dfsb = :$$sb, dfeukz = :ereukz,
     c+          dfeunr = :ereunr, dfift1 = :erift1,
     c+          dfift2 = :erift2, dfaeus = :eraeus,
     c+          dfaews = :eraews, dfaetm = :eraetm,
     c+          dfbust = :erbust, dfbunr = :erbunr,
     c+          dfjp = :erjp,
     c+          dfzbd = :erzbd, dfnetg = :ernetg,
     c+          dfvltg = :ervltg, dfskp1 = :erskp1,
     c+          dfskt1 = :erskt1, dfskp2 = :erskp2,
     c+          dfskt2 = :erskt2, dfskp3 = :erskp3,
     c+          dfskt3 = :erskt3, dfesrn = :eresrn,
     c+          dfbgts = :erbgts, dfbgt1 = :erbgt1,
     c+          dfbgt2 = :erbgt2, dfbdm = :erbdm,
     c+          dfbsh = :erbsh, dfefeb = :erefeb,
     c+          dfbuwg = :erbuwg, dfbuks = :erbuks,
     c+          dfbuku = :erbuku, dfbueh = :erbueh,
     c+          dfscc = :erscc, dfhk = :erhk,
     c+          dfpljp = :erpljp, dfsusd = :ersusd,
     c+          dfkoz = :erkoz, dfersl = :erersl,
     c+          dferst = :ererst, dfefsk = :erefsk,
     c+          dfbsl = :erbsl, dfbst = :erbst, dffill = :erfill,
     c+          dfbgjt = :##bgjt, dfefjt = :##efjt, dfaejt = :##aejt,
     c+          dffljt = :##fljt, dfvljt = :##vljt, dffujt = :##fujt,
     c+          dfskj1 = :##skj1, dfskj2 = :##skj2, dfskj3 = :##skj3
     c+      where dfbgnr = :erbgnr
     C/END-EXEC

Wenn ich das Programm im Debug, SQL-Ausgabeansicht, laufen lasse, werden alle Felder korrekt gefüllt angezeigt! Es erscheint keine Fehlermeldung, aber das Update hat nicht stattgefunden.

Mit DSPJOBLOG bekomme ich folgendes zusehen:

2 > call ndms995r '000079700232369'               
    ODP wiederverwendet.                          
    ODP nicht gelöscht.                           
    Eingebettetes SELECT beendet.                 
    ODP wiederverwendet.                          
    ODP nicht gelöscht.                           
    Wert für Spalte oder Variable DFNAME zu lang.

Aktuell fällt mir nu nichts mehr ein.

Vielleicht hat ja jemand noch eine Idee wo ich ansetzen kann! Danke!!


Gruß

Andreas

[KM]

Hallo,

wie sieht's mit Commit-Steuerung aus?

Gruß,
KM

[Fuerchau]

" Wert für Spalte oder Variable DFNAME zu lang" ist eine eindeutige Fehlermeldung!
Du bekommst sicherlich einen negtiven SQLCOD.

Scheinbar ist die Prüfung auf korrekte Werte in V7R1 verschärft worden.
Vergleiche die Definition von DFNAME mit dem Inhalt von p0ktbz.

[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