-
RDi Dynamisches SQL Fehler RNF0401E Fehler während der Kommunikation mit dem Host
Hallo Forum,
ich habe ein Problem mit RDi Editor. Wenn ich dynamisches SQL editiere bekomme ich im Editor immer den Fehlercode RNF0401E angezeigt.
Der Compiler meldet keine Fehler.
RDI Version 9.1.1
I Version 7.2 mit den neusten Ptf´s
PHP-Code:
ctl-opt alwnull(*inputonly) ;
dcl-ds DateiDatenStruktur EXTNAME('FTYPF010') end-ds; dcl-s sql_Txt char(1024); dcl-s yFir like(ftyfir) inz(1); dcl-s yFty like(ftyfty) inz(10);
sql_txt='select * from ftypf010 where ftyfir= ? and ftyfty< ?';
exec sql prepare sql_stmt from :sql_txt; RNF0401E Während der Kommunikation mit dem Host ist ein Fehler aufgetreten. exec sql declare c1 cursor for sql_Stmt; RNF0401E Während der Kommunikation mit dem Host ist ein Fehler aufgetreten. exec sql open C1 using :yFir, :yFty; RNF0401E Während der Kommunikation mit dem Host ist ein Fehler aufgetreten.
dow sqlstt <>'02000'; exec Sql fetch c1 into:DateiDatenStruktur; RNF0401E Während der Kommunikation mit dem Host ist ein Fehler aufgetreten.
if sqlstt ='02000'; leave ; endIf ; dsply Ftyfty; endDo ;
exec sql close C1;
*inlr = *on ;
-
Hallo,
das ist auch kein Fehler vom Code. Sonder der RDi versucht für die Syntaxprüfung eine Verbindung zum Server herzustellen.
Wenn du die Verbindung wieder herstellst sollte das Problem behoben sein.
lg Andreas
-
Hallo Andreas
Die Verbindung besteht. Zumindesten kann nicht nicht erkennen das die Verbindung nicht steht. Aus dem RDI kann ich auch Kompilieren oder auch debuggen.
Non SQL Funktionen werden im Editor ja auch nicht angemeckert.
Olaf
-
Die SQL Syntaxprüfung führt der RDi direkt am Server durch.
Dafür gibt es auch ein eigenes Setting:
Menü Fenster --> Benutzervorgaben --> Ferne Systeme --> LPEX-Editor ... --> ILE RPG
Hier die Option "Automatische Syntaxprüfung" --> "Autom. Syntaxprüfung von SQL Anweisungen (am Server)"
Und für genau dieses benötigt er eine Verbindung.
Eventuell sind einige Service nicht gestartet?
Läuft die QUSRWRK?
-
Nur so zur Sicherheit!
Hast Du auch geprüft, ob die Quelle den Typ SQLRPGLE und nicht nur RPGLE hat?
Noch ein paar Hinweise:
1. für diese Art von Abfrage ist kein dynamisches SQL erforderlich, d.h. statisches wäre ausreichend.
2. Du solltest nur die Spalten Selektieren, die Du tatsächlich brauchst (an dieser Stelle funktioniert SQL anders als RPG!)
3. Man sollte niemals Variablen mit SQL oder SQ beginnen lassen, da IBM sich solche Variablen für den SQL-Precompiler reserviert hat. Selbst wenn heute noch alles ordentlich läuft, könnte im nächsten Release oder mit dem nächsten Technology Refresh eine zusätzliche Variable, mit dem gleichen Namen wie Deine Variable hinzugefügt werden. Das beste, das Dir dann passieren kann ist, dass Dein Programm nicht mehr umgewandelt werden kann. Viel schlimmer wäre es, wenn das Ganze in irgenwelchen wilden Ergebnissen enden würde.
4. Es sollte nie auf SQLSTATE = 0200 oder SQLCODE = 0 abgefragt werden, sondern immer auch die Fehlersituationen berücksichtigt werden.
Birgitta
-
@andreas Ich habe nun die Verbindung getrennt und erneut verbunden. Der Fehler taucht nun nicht mehr auf. Besten Dank für die Hilfe
@birgitta SQLRPGLE ja,
1) das ist korrekt. Bin nur dabei etwas zu testen.
2) Danke für die Info.
3) War mir bis dato nicht bekannt. Wo kann man den soetwas nachlesen?
4) Welche SQL Status muß ich dann abfragen?
-
Zitat von B.Hauser
4. Es sollte nie auf SQLSTATE = 0200 oder SQLCODE = 0 abgefragt werden, sondern immer auch die Fehlersituationen berücksichtigt werden.
Das ist ein guter Tipp von Birgitta!
Bei uns hab ich das so eingeführt, dass bei einem Error oder Warning eine ESCAPE Message mit QMHSNDPM gesendet wird. Wodurch das Standard Errorhandling der Anwendung greift.
Kurz:
* Anfangs die Declarationen für SQL
Code:
Exec Sql Whenever SQLERROR Goto SQLERROR;
Exec Sql Whenever SQLWARNING Goto SQLERROR;
Exec Sql Whenever NOT FOUND CONTINUE;
* Dann den Fehler/Warnung ermitteln
* Und mit QMHSNDPM senden.
-
@3) War mir bis dato nicht bekannt. Wo kann man den soetwas nachlesen?
@4) Welche SQL Status muß ich dann abfragen?
SQLCODE < 0 = Error
SQLCODE >= 0 und <> 100 (Satz gefunden, mit oder ohne Warnung)
SQLCODE = 100 (Satz nicht gefunden)
Ob es sich bei dem SQL Status um einen Fehler, eine Warnung oder nicht gefunden handelt hängt von den ersten beiden Stellen des SQL Status ab:
00 = Alles OK
01 = Warnung
02 = Nicht gefunden
Weder 00 noch 01 noch 02 = Fehler
Was mich bei der Lösung von Andreas stört, ist dass der WHENEVER einen GOTO bzw. einen TAG benötigt, was im Free Format RPG nicht zulässig ist.
Wir haben eine Funktion, die nach jedem SQL-Statement aufgerufen wird und die den SQLCODE prüft. Im Fehlerfall wird die Fehlernachricht ermittelt und als Escape Message zurückgegeben.
Einiges kann man in Database Embedded SQL Programming nachlesen.
Birgitta
Similar Threads
-
By ubas in forum NEWSboard Programmierung
Antworten: 1
Letzter Beitrag: 20-05-14, 15:12
-
By camouflage in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 03-02-14, 09:45
-
By Christof in forum IBM i Hauptforum
Antworten: 5
Letzter Beitrag: 20-10-05, 11:22
-
By K_Tippi in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 05-12-02, 11:41
-
By otto in forum IBM i Hauptforum
Antworten: 6
Letzter Beitrag: 19-09-02, 17:50
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks