Varable SQL mit verschiedenen LIBS

[steven_r]

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

[Fuerchau]

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.

[steven_r]

danke hab ich mir fast gedacht,
werde es mit einen Dynamischen sql lösen.

mfg
steven_r

[BenderD]

Hallo,

am saubersten mit set schema und dann unqualifiziert zugreifen. Die mittlere Huddelvariante geht mit dynamic SQL, die huddeligste Variante mit OVRDBF ...


die oberhuddeligste Variante geht mit dem LIBL, die funktioniert nicht einmal zuverlässig, da dieser nur bei der ersten Zuordnung zieht.


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

[steven_r]

Hallo´,

und wie funktioniert das mit SET SCHEMA?

danke.

lg
steven_r

[Fuerchau]

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

[BenderD]

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

[JonnyRico]

Hi,

auch in Sachen Performance ist das SET SCHEMA dem dynamischen SQL vorzuziehen.

Gruß

Sascha

[Fuerchau]

@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

[BenderD]

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

[BenderD]

Hallo,

das sind eher wieder Erdnüsse, nach Wechsel des Schema muss auch vom Optimizer neu gerechnet werden.

mfg

Dieter Bender

Hi,

auch in Sachen Performance ist das SET SCHEMA dem dynamischen SQL vorzuziehen.

Gruß

Sascha