SQL mit variablen Tabellennamen

[B.Hauser]

Hallo,

der SQLCOD/SQLCODE oder der SQLSTT/SQLSTATE sollte nach jedem SQL-Statement geprüft werden. (Das hatte ich der Einfachheit halber in meinem Beispiel weggelassen)
Gerade bei dynamischem SQL kann es leicht passieren, das die Syntax nicht stimmt. Dann würde schon das Prepare-Statement scheitern.

Was welcher SQL-Code bedeutet kann relativ einfach ermittelt werden:
Alle SQL-Nachrichten sind in der Nachrichten-Datei QSQLMSG hinterlegt. Die Message-Id setzt sich zusammen aus SQL + Absolut-Wert des SQL-Codes, z.B. -204 --> SQL0204.

Für weitere Informationen würde ich Dir empfehlen doch mal die Online-Bibliothek zu konsultieren.
In den folgenden Redbooks findest Du einiges an Beispiel-Codes und auch relativ einfache und gute Erklärungen zu dem Thema Embedded SQL.
Who Knew You Could Do That with RPG IV? A Sorcerer's Guide to System Access and More

Modernizing IBM eServer iSeries Application Data Access - A Roadmap Cornerstone

Ansonsten findest Du noch Beispiele in:
Embedded SQL Programming

Noch eine allgemein Anmerkung:
Host-Variablen sollten niemals mit SQL, SQ, RDI oder DSN beginnen. Diese Variablen sind für den Datenbanken-Manager reserviert. Selbst wenn heute noch keine Probleme auftreten, kann in einem zukünftigen Release IBM eine Variable mit einem Namen, der bereits als Hostvariable definiert wurde, verwenden. Im besten Fall stürzt das Programm ab. Im schlimmsten Fall werden wichtige Werte überschrieben und kein Mensch kann sich erklären was passiert ist.

Birgitta

[Squall]

Hallo,

ja es findet schon beim Prepare ein Fehler statt.

Nachrichten-ID . . . . . . . :   SQL0311                                       
Nachrichtendatei . . . . . . :   QSQLMSG                                       
  Bibliothek . . . . . . . . :     QSYS                                        
Nachrichtentext  . . . . . . :   Länge einer Host-Variablen variabler Länge oder
 einer LOB-Host-Variablen ungültig. 

Aber ist jetzt mein SQLSTM(jetzt STMSQL ^^) zu lang?
D STMSQL 1024A varying

Eine andere Variable wird ja im Prepare nicht benutzt.

Gruß Martin

[Fuerchau]

Prüfe genau den Inhalt deiner Variablen STMSQL (ggf. hex, dann wird auch das Längenattribut angezeigt), ggf. lass besser das varying weg.

[Squall]

Es lag scheinbar am varying. Aber meinen Qualifizierten Namen mag er nicht. Entweder SQL5016(Qualifizierter Objektname &1 nicht gültig.): LIB.FILE
oder SQLCOD0104(Token &1 ungültig. Gültige Token: &2.) bei LIB/FILE oder nur FILE.

Gibt es noch andere Zusammensetzungsmöglichkeiten?

Gruß Martin

[Fuerchau]

Schau dir den String mal genau (auch HEX) an. Vielleicht enthält dein STMSQL ja irgendwo ungültige Zeichen, ansonsten kann ich mir das nicht erklären.

Ggf. ist das auch VARPG-spezifisch, dass nicht mit mehreren LIB's umgegangen werden kann.
In diesem Fall musst du OVRDBF's (per CALL) absetzen und ohne Qualifizierung arbeiten.

[Squall]

Ich arbeite zz ja gerade einmal mit einer Lib. Es ist ein ganz einfacher "Select * from Lib/Table".

Ich habe auch schon probiert das Programm nur auf der i5 auszuführen, bzw den String fest ins Programm zu schreiben. Hat leider beides nichts geholfen.

Muss die zu compilierende Datei evtl von einer anderen Art als SQLRPGLE sein?

Gruß Martin

[Fuerchau]

Die Art des Programmes bleibt SQLRPGLE.
Mach das Ganze mal auf der AS/400 und schau dann mal ins Joblog. Hier muss es weitere Hinweise geben.

[Squall]

Ich habe den Fehler gefunden. Den '*' mag er nicht. Dh. es gibt keine Möglichkeit alle Felder zu selektieren ohne alle anzugeben?

Gruß Martin

[Fuerchau]

Das mag ein Problem sein, allerdings gibt es für so was die Describe-Befehle um die Feldnamen einer Tabelle zu ermitteln.

Anscheinend wird "select * ..." nur vom CLI-Interface unterstützt.

[Squall]

Also müsste ich mir um einen "Select * ..." abzusetzen ein ILE RPG Programm mit CLI schreiben... Das ist auch etwas dumm von IBM umgesetzt worden...

Auf jeden Fall danke für die Information.

Gruß Martin

[Fuerchau]

Das ist gar nicht dumm sondern liegt am Prinzip des embedded SQL's.
Per
describe table :SqlTableName into :SQLDA
kannst du entsprechende Information abfragen.
Eine SQLDA kannst du vorher anlegen, den Select kannst du dann entsprechend zusammen bauen.

Zugegeben etwas mühsam, aber ich habe es so bisher immer gemacht.
Mein Tool SQLCPY arbeitet genau so.