View Full Version : Varable SQL mit verschiedenen LIBS
Hallo zusammen,
erst mal ein gutes neues Jahr an alle.
Ich habe ein Programm SQLRPGLE wo ich per SQL auf eine Datei zugreifen möchte die es in verschiedenen Libs gibt, die Umgebung kann sich der User aussuchen.
Kann ich das im code varable gestalten?
ungefähr so:
/exec sql
c+ SELECT sum(menge) as summe, kdnr c+ FROM :LIB/file
c+ .............
c/end-exec
danke im vorraus
mfg
steven_r
Dies geht leider nicht.
Du musst dann vor Ausführung des Select's einen OVRDBF durchführen oder die Bibliothek in die LIBL aufnehmen (auch wenn Dieter dagegen ist).
Wichtig ist dann allerdings NAMING=*SYS !
Alternativ geht natürlich immer dynamisches SQL mit Prepare.
danke hab ich mir fast gedacht,
werde es mit einen Dynamischen sql lösen.
mfg
steven_r
Hallo,
am saubersten mit set schema und dann unqualifiziert zugreifen. Die mittlere Huddelvariante geht mit dynamic SQL, die huddeligste Variante mit OVRDBF ...
<edit>
die oberhuddeligste Variante geht mit dem LIBL, die funktioniert nicht einmal zuverlässig, da dieser nur bei der ersten Zuordnung zieht.
</edit>
mfg
Dieter Bender
Hallo zusammen,
erst mal ein gutes neues Jahr an alle.
Ich habe ein Programm SQLRPGLE wo ich per SQL auf eine Datei zugreifen möchte die es in verschiedenen Libs gibt, die Umgebung kann sich der User aussuchen.
Kann ich das im code varable gestalten?
ungefähr so:
/exec sql
c+ SELECT sum(menge) as summe, kdnr c+ FROM :LIB/file
c+ .............
c/end-exec
danke im vorraus
mfg
steven_r
Hallo´,
und wie funktioniert das mit SET SCHEMA?
danke.
lg
steven_r
Stimmt: SET SCHEMA überschreibt für unqualifizierte SQL's die NAMING-Konvention.
Also Achtung:
SET SCHEMA MYLIB
select * from myfile <= wird in MYLIB gesucht
SET SCHEMA DEFAULT
select * from myfile <= wird in USER (*SQL) bzw LIBL(*SYS) gesucht
"SET SCHEMA XXXX" kann auch dynamisch direkt per EXECUTE angewendet werden, ob XXXX exisitiert wird erst beim nächsten Zugriff geprüft. Im Zweifel heißt es lapidar "Datei nicht gefunden" und nich "XXX nicht gefunden".
Hallo,
das geht sogar statisch
MySchema = 'HUGO'
// end free und exec sql gedöns
SET SCHEMA :MySchema
// end exec und free gedöns
Ab jetzt gehen alle unqualifizierten Zugriffe auf die Datei im CURRENT_SCHEMA, das oben gesetzt wurde (naming *SQL, versteht sich)
Im Fehlerfall kommt dann Datei Blablabla in HUGO nicht gefunden.
mfg
Dieter Bender
Stimmt: SET SCHEMA überschreibt für unqualifizierte SQL's die NAMING-Konvention.
Also Achtung:
SET SCHEMA MYLIB
select * from myfile <= wird in MYLIB gesucht
SET SCHEMA DEFAULT
select * from myfile <= wird in USER (*SQL) bzw LIBL(*SYS) gesucht
"SET SCHEMA XXXX" kann auch dynamisch direkt per EXECUTE angewendet werden, ob XXXX exisitiert wird erst beim nächsten Zugriff geprüft. Im Zweifel heißt es lapidar "Datei nicht gefunden" und nich "XXX nicht gefunden".
Hi,
auch in Sachen Performance ist das SET SCHEMA dem dynamischen SQL vorzuziehen.
Gruß
Sascha
@Dieter
Auch bei Naming *SYS zieht dann CURRENT_SCHEMA (ich habs zumindest im STRSQL mal ausprobiert). Erst bei DEFAULT zieht wieder *LIBL.
Kleiner Lacher:
Ein LIB mit Namen DEFAULT funktioniert übrigens nicht ;)
Hallo,
current_schema ist wohl curlib und dann passt es wieder; das andere geht mit: set schema "DEFAULT"
, das ist ein ähnlicher Effekt wie eine Spalte die USER heißt (reservierter Name in SQL)
mfg
Dieter Bender
@Dieter
Auch bei Naming *SYS zieht dann CURRENT_SCHEMA (ich habs zumindest im STRSQL mal ausprobiert). Erst bei DEFAULT zieht wieder *LIBL.
Kleiner Lacher:
Ein LIB mit Namen DEFAULT funktioniert übrigens nicht ;)