View Full Version : ODBC iSeries und logische Dateien...
Hallo zusammen!
Gibt es über CLI/ODBC eine Möglichkeit herauszufinden,
zu welcher physischen Datei eine logische Datei gehört?
D.h. irgendein treiberspezifisches Attribut einer
SQLxxx-Funktion, wo der iSeries Access ODBC-Driver
diese Information hineinstellt?
(Also z.B. die Information "Basiert auf Datei" bei DSPFD)
Im "iSeries Access for Windows:Programming"-PDF
konnte ich auf die Schnelle nichts Entsprechendes finden
(vielleicht liegt's ja auch an meiner Suchweise...).
Danke für Infos+Tipps
lg
Chris
Es gibt nur den Weg von PF zur LF, nicht umgedreht.
Für eine PF kann man per CLI-SQLStatistics() die zugehörigen LF's abfragen.
Index-Schemainformationen liefern keine LF's, wenn sie nicht per SQL mit CREATE INDEX erstellt wurden.
Ansonste ist aus ODBC-Sicht eine LF eben eine Tabelle, an der selber leider keine LF's hängen können. Deshalb gibts da per ODBC/CLI keine Informationsmöglichkeiten.
Der Zugriff auf eine LF als TABLE ist eben AS/400-spezifisch.
Alles klar!
Danke f.d. Info!
Den Weg PF -> LF verwenden wir bereits, müssen die
Sache also offensichtlich andersrum angehen.
lg
Chris
Mal ne Frage, für was brauchst du denn die LF-Infos, wenn SQL die LF's nur zur Optimierung benötigt ?
select view_name, tyble_name
from mySchema.sysviewdep
where view_name myView
oder halt QSYS2 für alle, dann mus man schema_name noch mit abfragen
D*B
könnte hier weiterhelfen
Hallo zusammen!
Gibt es über CLI/ODBC eine Möglichkeit herauszufinden,
zu welcher physischen Datei eine logische Datei gehört?
D.h. irgendein treiberspezifisches Attribut einer
SQLxxx-Funktion, wo der iSeries Access ODBC-Driver
diese Information hineinstellt?
(Also z.B. die Information "Basiert auf Datei" bei DSPFD)
Im "iSeries Access for Windows:Programming"-PDF
konnte ich auf die Schnelle nichts Entsprechendes finden
(vielleicht liegt's ja auch an meiner Suchweise...).
Danke für Infos+Tipps
lg
Chris
Mit DSPFD kann man auch abfragen, welche PF's zu einer LF gehören.
Danke für die Tipps!
Das mit sysviewdep klappt in der Form leider nicht.
Ich nehme an, es liegt daran, dass es "echte" logische
Dateien sind, die nicht mittels SQL angelegt wurden.
@Fuerchau:
Wir brauchen das in dieser Form, da zum Kompilationszeitpunkt
die Datei noch nicht feststeht. Es kann zur Laufzeit also
durchaus sein, dass eine logische Datei
(durch Anwender ausgewählt) verarbeitet werden muss.
lg
Chris
Das kann man aber verhinderen, da Schema-Informationen SQLTables() diese LF als VIEW ausweisen.
Man kann also durchaus die Auswahl von VIEWS verhindern.
Andererseits ist eine LF eben genau wie eine PF zu behandeln.
dann könnte man immer noch in dem QAD* Geraffel in der QSYS rumstochern, da müsste das drin stehen, ist aber nicht unbedingt Release fest. Wenn man ein ordentliches Change Management hat, könnte man die Info auch nach Erstellung von logischen Dateien automatisiert abstellen.
Was die Anforderung betrifft, das sieht doch danach aus, dass in Wirklichkeit eine Sortierung ausgewählt wird, das geht dann aber mit einem dynamisch erzeugten SQL Statement mit der entsprechenden order by Klausel wesentlich eleganter - und das ist auch für den Anwender dann durchschaubarer und flexibler.
D*B
Danke für die Tipps!
Das mit sysviewdep klappt in der Form leider nicht.
Ich nehme an, es liegt daran, dass es "echte" logische
Dateien sind, die nicht mittels SQL angelegt wurden.
@Fuerchau:
Wir brauchen das in dieser Form, da zum Kompilationszeitpunkt
die Datei noch nicht feststeht. Es kann zur Laufzeit also
durchaus sein, dass eine logische Datei
(durch Anwender ausgewählt) verarbeitet werden muss.
lg
Chris
Seit Einführung der QSYS2/SYSxxx stehen die QSYS/QAD* meist auf *PUBLIC *EXCLUDE, so dass man da nicht mehr so einfach wie früher (vor V4R3) drankommt.
Aber das ist dann nicht mehr DB-neutral.