Anmelden

View Full Version : Embedded SQL Newbie



JonnyRico
26-10-04, 16:24
Hallo,

ich habe das letzte Thema schon mitgelesen. Der Workshop von Birgitta sieht auch sehr interessant und gut aus. Ich wollte jetzt allerdings mal kein starten und ein ganz "einfaches" Delete auf eine Tabelle machen. Das ganze sieht dann bei mir so aus:

FERRPF O E disk RENAME(ERRPF:SQLSATZ)
DKUNDE S 5A

/FREE
Kunde='ZZ001';
/END-FREE

C/Exec SQL
C+ Delete
C+ From TEMP/KUNDEN
C+ Where KDNR = :Kunde
C/End-Exec
C move SQLCOD Err
C write sqlsatz
C seton LR

Allerdings wird der Kunde nicht gelöscht. Ich habe dann dann die "ERRPF" mit eingebaut um den Fehler zu sehen. Er scheibt Fehlercode "700Q". Was bedeutet das? Gibt es ein Handbuch indem ich die Fehlercodes finde? Liegt das irgendwo als PDF vor? Vielen Dank im Voraus.

Gruß

Sascha

Fuerchau
26-10-04, 16:34
Den Fehler kenn ich zwar nicht (müsste was im Joblog stehen), aber setze mal das Commit aus:

/exec sql set option commit=*none
/end-exec

JonnyRico
27-10-04, 06:42
Ja danke daran lag es. Im Joblog steht die Meldung Teildatei KUNDEN nicht in Journal *N aufgezeichnet. mit Commit=*NONE funktioniert es. Wie hägt das mit dem Commit und dem Journal denn zusammen?

Bruno Jakob
27-10-04, 07:07
Commitment Control setzt die Journalisierung voraus. Irgendwo muss ja stehen, was im Fehlerfall zurückgesetzt werden muss. Und da ist der Journalreceiver, der diese Informationen aufnimmt.

Gruß
Bruno

B.Hauser
27-10-04, 07:48
Gibt es ein Handbuch indem ich die Fehlercodes finde?

Hallo Sascha,

bei jedem SQL-Statement wird die SQLCA gefüllt.
Aus den Feldern SQLCOD und SQLSTT kannst Du den Fehler-Status entnehmen.

SQLCOD ist Standard iSeries / SQLSTT ist SQL-Standard.
Zu einem SQLSTT kann es mehrere SQLCODs geben.

Beschreibungen zu den SQLCODs findest Du unter:
SQL Message Finder (http://publib.boulder.ibm.com/infocenter/iseries/v5r3/ic2924/index.htm?info/rzala/rzalafinder.htm)

Ansonsten kann man den Nachrichten-Text auch direkt aus der entsprechenden Nachrichten-Datei entnehmen. Wie das geht steht in folgendem Artikel:

Vom SQLCOD zur Fehlernachricht (http://www.inn-online.de/iNN-eNews0304.html#Tekki1)

Der SQLCOD "700Q" müsste allerdings falsch sein. Die Fehlercodes für Commitment-Steuerung sind alle im Bereich 7000. Wie ist dein Ausgabe-Feld Err definiert? Binär oder Integer? Wenn nicht könnte das ein Problem sein.

Birgitta

BenderD
27-10-04, 08:45
Hallo,

genauer müsste man sagen: irgendwo muss ja festgelegt werden in welches Journal protokolliert wird. Falls man nämlich nur After Images erzeugen lässt, kann man trotzdem mit Commit arbeiten (dann wird nämlich die Journalisierung automatisch eskaliert).
Ich würde allerdings generell zur Journalisierung aller Dateien mit before und after images raten - auch wenn man keine Commit Steuerung einsetzt; alleine die Vorteile bei Fehler Abklärungen sind es wert.

mfg

Dieter Bender


Commitment Control setzt die Journalisierung voraus. Irgendwo muss ja stehen, was im Fehlerfall zurückgesetzt werden muss. Und da ist der Journalreceiver, der diese Informationen aufnimmt.

Gruß
Bruno

Fuerchau
27-10-04, 09:19
SQL-Fehlercodes sind grundsätzlich Negativ !
700Q ist also als negativer Wert zu interpretieren (im Debugger wird das auch negativ angezeigt: -7008.)
Positve Codes sind keine Fehler sondern Warnungen (z.B. 100=EOF).
SQL-Fehler findest du in der QSQLMSG (wrkmsgd () qsqlmsg) mit der ID SQLxxxx.