Programm 'QSQROUTE' - Unklarer "ückkehr-Status"

[roman]

Guten Tag
Ich habe folgendes Problem mit einem embedded SQL in RPG:
Im Programm habe ich den nachstehenden Befehl, syntaktisch korrekt definiert.
SELECT ADLPLN * 100 ,ADLPBR * 100 ,ADLPHO * 100 INTO :LP_lang , :LP_breit , :LP_hoch FROM LO1010 WHERE ADFIRM = 270 and ADLAHA = :lp_LAHA and ADLPS1 = :lp_LPS1 and ADLPS2 = :lp_LPS2 and ADLPS3 =
:lp_LPS3 and ADLPS4 = :lp_LPS4

In der Mehrheit der Fälle (!) erfolgt die Ausführung korrekt. In einem Fall (mit DBG festgestellt) ist der Inhalt im Feld SQL_00068 = "0", d.h. die im Select definierten Resultatwerte werden nicht aktualisiert.

Kann mir jemand sagen, unter welchen Bedingungen der Wert im Feld SQL_00068 den Wert '0' bekommt. Ich kann den Fehler einfach nicht nachvollziehen.

Besten Dank für eine Erklärung.

Grüsse Roman


Hier der Debugging-Code:
553 C* :LP_breit , :LP_hoch FROM LO1010 WHERE ADFIRM = 270 and A
554 C* :lp_LAHA and ADLPS1 = :lp_LPS1 and ADLPS2 = :lp_LPS2 and
555 C* :lp_LPS3 and ADLPS4 = :lp_LPS4
556 C*END-EXEC
557 C EVAL SQL_00070 = LP_LAHA
558 C EVAL SQL_00071 = LP_LPS1
559 C EVAL SQL_00072 = LP_LPS2
560 C EVAL SQL_00073 = LP_LPS3
561 C EVAL SQL_00074 = LP_LPS4
562 C Z-ADD -4 SQLER6
563 C CALL 'QSQROUTE'
564 C PARM SQLCA
565 C PARM SQL_00065
566 C SQL_00068 IFEQ '1'
567 C EVAL LP_LANG = SQL_00075
568 C EVAL LP_BREIT = SQL_00076
569 C EVAL LP_HOCH = SQL_00077
570 C END
571 *

[Fuerchau]

Wenn der Select mehr ale eine Zeile liefert, können die Ergebnisse nicht abgerufen werden da hier ohne Cursor gearbeitet wird.

Diese direkte Form des Select's ist nur erlaubt wenn wirklich nur 1 Zeile als Ergebnis kommen kann.

Prüfe an Hand deiner Where-Bedingung, ob da nicht mehrere Ergebnissätze vorliegen können. In diesem Fall musst du halt doch mit Declare Cursor, Open, Fetch, Close arbeiten.

PS:

Prüfe auch SCLCOD und SQLSTA sowie das Joblog !

[roman]

Besten Dank für die prompte Antwort.

Also die Abfrage ist so definiert, dass ausschliesslich ein Satz gefunden wird.

Beim Untersuchen des Logs habe ich allerdings folgende Meldung festgestellt: "Zeile für SELECT nicht gefunden."
Dies erklärt mir den "Status 0"

Den gleichen Befehl habe ich (ohne Hostvariabeln) unter STRSQL getestet. Dabei wurde der gesuchte Satz gefunden. Ich habe jene Werte verwendet, die ich mittels Abfrage innerhalb des Debugging erhalten habe.

[roman]

Alles Ok! Danke für die Hinweise

Gruss Roman

[Fuerchau]

Die, vom Pre-Compiler generierten Felder sollte man auf keinen Fall auswerten. Für eine korrekte Auswertung von Fehlern sollte man auf die SQLCA-Struktur und das Feld SQLCOD zugreifen. Nur diese enthalten weitere Informationen welcher Fehler denn vorliegt.

PS:
Woran lags denn nun ?

[roman]

Die, vom Pre-Compiler generierten Felder sollte man auf keinen Fall auswerten. Für eine korrekte Auswertung von Fehlern sollte man auf die SQLCA-Struktur und das Feld SQLCOD zugreifen. Nur diese enthalten weitere Informationen welcher Fehler denn vorliegt.

PS:
Woran lags denn nun ?

Nein, nein - über die generierten Felder bin ich nur auf die Fehlersituation gestossen - ich wollte diese natürlich nicht auswerten.

Zur Ursache: Peinlich, peinlich - ich wollte es eigentlich verheimlichen - ein eigentlicher Anfängerfehler der mir nicht hätte unterlaufen dürfen: Das Pgm verarbeitete eine (ältere) Datei die in der LIBL vorgelagert war und eben den gesuchten Satz nicht enthielt. Meine Tests in der SQL-Umgebung bezogen sich auf die aktuelle Datei...

[malzusrex]

ach, das ist doch noch harmlos.

ich habe es schon geschaft, auf der kundenmaschine daten platt zu machen. hatte wieder mal 4-5 sitzungen offen und war auf verschiedene systemen(unser entw.sys und 2 kundensys.). dann mal eben ein CLRPFM und beim enter (bzw NACH dem enter) gemerkt das es nicht mein system war .
hat mir ne nachtschicht eingebracht, um alles wieder zu bekommen ..


schöne nacht noch
ronald