ODBC iSeries und logische Dateien...

[caltmann]

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

[Fuerchau]

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.

[caltmann]

Alles klar!
Danke f.d. Info!
Den Weg PF -> LF verwenden wir bereits, müssen die
Sache also offensichtlich andersrum angehen.
lg
Chris

[Fuerchau]

Mal ne Frage, für was brauchst du denn die LF-Infos, wenn SQL die LF's nur zur Optimierung benötigt ?

[BenderD]

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

[UFK]

Mit DSPFD kann man auch abfragen, welche PF's zu einer LF gehören.

[caltmann]

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

[Fuerchau]

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.

[BenderD]

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

[Fuerchau]

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.

[caltmann]

..das mit dem SQL ORDER BY ist ohnehin schon angedacht,
erfolgt aber sicher erst in einer späteren Phase,
bzw. können wird das nach auslesen der SQLStatistics
der physischen Datei dann ohnehin leicht realisieren,
im Moment sollen gewisse Programmteile einfach
1:1 übernommen werden,
um die Anwender so wenig wie möglich zu verwirren.
(Parallelbetrieb iSeries / Windows soll möglich sein)
Danke + lg
Chris

[BenderD]

dann ist die SYSKEYS dein Freund, die PF muss der RLA Schinken kennen (irgendwo muss der ja rein lesen) und aus der SYSKEYS kann man sich dann unmittelbar den ORDER BY zusammensetzen.

D*B

..das mit dem SQL ORDER BY ist ohnehin schon angedacht,
erfolgt aber sicher erst in einer späteren Phase,
bzw. können wird das nach auslesen der SQLStatistics
der physischen Datei dann ohnehin leicht realisieren,
im Moment sollen gewisse Programmteile einfach
1:1 übernommen werden,
um die Anwender so wenig wie möglich zu verwirren.
(Parallelbetrieb iSeries / Windows soll möglich sein)
Danke + lg
Chris