SQL mit variablen Tabellennamen

[THH]

Hallo Zusammen.

Ich habe da mal nen Problem für SQL
Spezialisten.

Ich habe ein RPG-Rprogramm ILE(nicht freiformat)

muss nun verschiedene Selects
auf verschiedene Tabellen machen

Problem ist, die Tabellen haben alle eine
unterschiedliche endung (xxx06 xxx07 xxx08 usw) des weiteren ligen sie auch noch in verschiedenen Bibliotheken.

wie bekomme ich nun ein statment
(select * from xxx where -----) wobei
xxx jeweils eine andere Tabelle sein kann
also ein variables select *

für schnelle hilfe währe ich dankbar

thomas

[GraueEminenz]

Hallo.

So spontan fällt mir da folgendes ein:

Den Tabellenname als Parameter an das Programm
übergeben.

Im Programm mittel Zeichkettenverarbeitung
den SQL-Ausdruck wie gewünscht zusammen daddeln
und mittel QCMDEXEC ein Runsqlstm durchführen.

MfG
GraueEminenz

[B.Hauser]

Hallo,

Wenn Dateien/Tabellen variabel gehandelt werden sollen gibt es zwei Möglichkeiten:

1. Statisches SQL verwenden und die benötigten Dateien mittels OVRDBF überschreiben. Die überschriebenen Dateien dann im SQL Statement verwenden.

2. Das SQL-Statement wird zu Laufzeit als String zusammengestellt und mit PREPARE in ein ausführbares SQL-Statement konvertiert.
Wenn Du mit einem SELECT-Statement arbeitest, muss Du einen Cursor verwenden.

Beispiel: (Es ist egal, ob die RPG-Statments im Free-Format oder nicht geschrieben sind. Die SQL-Statements könnten sogar in RPGIII-Code eingebunden werden!)

StringSQL = 'Select * from ' + LibFile +                           
            ' Where Feld1 = ''' + MyVar1 + ''' and Feld2 = ' + MyVar2 +     
             ' For Read Only';
 /End-Free
C/Exec SQL Prepare PrepSQL from :StringSQL      
C/End-Exec                                      

C/Exec SQL Declare CsrC1 Cursor For PrepSQL  
C/End-Exec                                             

C/Exec SQL Open CsrC1         
C/End-Exec                    
 
C                                  Do     *HiVal
C/Exec SQL  Fetch next from CsrC1 into :MyDS    
C/End-Exec                                     
 /Free
     If SQLCod = 100; //Datei-Ende
        Leave;
     Endif;
     If SQLCod < *Zeros; //Fehler
        //Fehler-Handling
     EndIf;
     // Weitere Verarbeitung
   EndDo;
 /End-Free
C/EXEC SQL Close CsrC1;
C/END-EXEC 

Sollten die Tabellen unterschieldlichen Aufbau haben, wird das Ganze um einiges komplizierter, d.h. es muss mit einer Descriptor-Area gearbeitet werden.

@Graue Eminenz
Select-Statements kannst Du nicht mit RUNSQLSTM verarbeiten, sondern nur Befehle wie Insert, Update, Delete aber auch Create Table u.a.

Birgitta

[Squall]

Hallo,

ich habe heute auch versucht mit dynamischen SQL zu arbeiten. Bekomme jedoch den Fehler 501 (Cursor beim Fetch geschlossen).

Mein Code:

Wird dem Programm übergeben: SQLSTM = 'Select * from LIB/Tab'

C/EXEC SQL                         
C+ Prepare MyStmt from :SQLSTM     
C/End-Exec                         
                                   
C/EXEC SQL                         
C+ Declare MyCsr Cursor for MyStmt 
C/END-EXEC 
            
C/EXEC SQL              
C+ Open MyCsr           
C/END-EXEC              
C                       
C/EXEC SQL              
C+ Fetch MyCsr          
C+       into :FLD1,  
C+            :FLD2,
C+            :FLD3 
C/END-EXEC 

Die Felder stimmen so. Schleife etc muss hierbei nicht beachtet werden, da es nur ein Ausschnitt meines Codes ist.

Gruß Martin

[Fuerchau]

Schau dir nach dem Open den SQLCOD an.
ggf. steht beim Create Programm das Naming aud *SQL dann musst du "LIB.TABLE" statt "LIB/TABLE" kodieren.

[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.