View Full Version : ODBC Problem mit V5R2M0
Hallo
Ich habe ja schon einen Beitrag eingestellt im Zusammenhang mit diesem.Wir haben folgendes Problem mit V5R2M0 (ODBC) deswegen erstmal wieder V5R1M0.
Seit V5R2M0 ist es so das wenn im ODBC Treiber eine Standartbibliothek gesetzt ist wird NUR die Standartbibliothek nach Tabellen und Programmen duchsucht,und nicht die *libl.
Wenn keine Standartbibliothek gesetzt ist wird die gesamte *libl duchsucht.
Wenn also eine Tabelle oder ein Programm aufgerufen wird das NICHT in der Standartbibliothek steht ,kommt die Message das Objekt konnte in(Standartbibliothek) nicht gefunden werden.
Man kann die StoredProcedures auch mit 2 Parameter neu umwandeln DFTRDBCOL (BIBLIOTHEKSNAME),aber nur eine leider keine *libl. und DYNDFTCOL(*YES).
dann geht es .
Gibt es da keinen anderen Weg ?
MfG
Hallo Homerun,
Du könntest weitere Bibliotheken getrennt mit Komma eingeben.
Gruss TARASIK
Hallo
Ja das ist richtig ,aber nur bei der *libl und nicht bei der Standartbibliothek,die curlib ist ja das Problem ,aber ich könnte die Standartbibliothek löschen und die der *libl hinzufügen,muß ich mal testen.
MfG
Ob in *LIBL oder nur in der DFTRDBCOL gesucht wird ist von der NAMING-Einstellung abhängig (über SET OPTION einstellbar):
NAMING=SYS: unqualifizierte Tabellen werden in *LIBL bzw. DFTRDBCOL (wenn <> *NONE) gesucht, Qualifizierung mit "LIB/TABLE".
NAMING=SQL: unqualifizierte Tabellen werden in einer Lib mit Namen des Users gesucht, Qualifizierung mit "LIB.TABLE".
DYNDFTCOL gilt ausschließlich für dynamische SQL's, also SQL's die erst zur Laufzeit erstellt werden (PREPARE/EXECUTE) und nicht bereits zur Compile-Zeit.
Bei SQL-Prozeduren gibt es (normalerweise) keine dynamischen SQL's !
Nun zu ODBC:
Dort gilt das gleiche wie oben !
D.h., die Standarddatensammlung entspricht der DFTRDBCOL (leer = *NONE).
Wird keine Bibliotheksliste eingegeben gilt der Systemwert QUSRLIBL !
NAMING wird in der ODBC-Konfiguration, Registerkarte "Server" eingestellt und (ups, siehe da), die Standardeinstellung ist SQL !
Ändere die Einstellung auf SYS und schon wird über *LIBL gesucht.
Hallo
Danke erstmal für deine Antwort,ich werde es mal testen.
MfG
Sven Schneider
23-01-04, 15:13
Besser als Fuerchau kann man das nicht beschreiben.
Die Art und Weise wie nach unqualifizierten SQL-Objekten gesucht ist allerdings in V5R2 nicht neu bzw. geändert worden.
Die Unterschiede zwischen *SYS und *SQL-Naming gibt es meines erachtens schon immer, min. aber seit OS/400 V3Rx.
Das einzig was neu ist, daß man in der ODBC-Datenquelle ein extra Feld für die Standardbibliothek angeben kann, ich weis allerding nicht warum.
Diese Bibliothek wird trotzdem nicht als CUR in die Bibliotheksliste gestellt, sondern nur als erste in die USR-Libl !!!
Die Libl des QZDAxxx-Jobs sieht also immer so aus :
*SYSLIBL SYS
QIWS PRD
Curlib aus USRPRF CUR (sofern angegeben)
*DFTRDBCOL USR
*USRLIBL USR
Sven
Seit es SQL gibt, wird NAMING zwischen SYS und SQL unterschieden. Im ODBC-Treiber (seit V5R1) hat man die DFTRDBCOL nur neu mit aufgenommen um die gleichen Funktionen wie direkt auf der AS/400 zu unterstützen (siehe z.B. CRTSQLRPG).
Früher war bei NAMING=SQL die Standardlib der Name des USERS !
Da aber Programme nicht nur unter einem User laufen sollten, ist das ein Problem. Mit DFTRDBCOL kann ich nun die Lib gezielt vorgeben, so dass auch verschiedene User mit der gleichen Lib arbeiten können.
Dies gilt aber nur für unqualifizierte SQL's (also ohne Lib).
Bei NAMING=SYS habe ich zwar diese Problem nicht, da unqualifizierte SQL's über LIBL gesucht werden, es kann aber zum Problem werden, wenn die Applikationsdateien z.B. kopiert werden und dann (ganz zufällig) in der CURLIB des Users landen.
Und nun ?
Deshalb ist der DTFRDBCOL ganz vernünftig um unqualifizierte SQL's verwenden zu können !
Nur dann kann ich relativ variable Anwendungen entwickeln, die je nach ODBC-Einstellung mit unterschiedlichen Lib's arbeiten kann.
Da stellt sich wieder die Frage, was ich mache, wenn eine Anwendung ihre Daten in mehrere Lib's verstreut ?
Tipp:
Wenn ich mit DAO arbeite, kann ich per "RegisterDatabase" einen korrekten ODBC-Eintrag erstellen und ggf. korrigieren.
Bei ADO kann ich die Libl direkt mittels der Connection-Properties einstellen.
Somit hat ein Anwender keine Chance, meine Libl's zu verbiegen und ich kann mit unqualifizierten SQL's arbeiten.
Sven Schneider
26-01-04, 17:16
Übrigens es gibt doch Unterschiede zwischen OS/400 V5R1 und V5R2.
Und zwar immer dann, wenn der SQL-Serverjob QZDAxxINIT eine Store Procedure (oder eine/ein externe Procedure/Programm mit embedded SQL) aufruft und diese dynam. SQL enthält.
Hier wird bei V5R1 der Parameter DFTRDBCOL nicht an die Store Procedure weitergereicht, sondern gilt nur für direkt ausgeführte SQL-Anweisungen.
Dieses wurde in V5R2 korrigiert.
Siehe :
http://www-912.ibm.com/s_dir/slkbase.NSF/0/8ad152c7ee9f931f86256ad2007ca075?OpenDocument
Ich homerun glaube das ist dein Problem.
Unabhängig davon, habe auch ich noch eine Frage (Fuerchau) :
Der Parameter DFTRDBCOL gilt als Ersatz für Naming, d.h. wenn eine DFTRDBCOL angegeben ist, dann wird für unqualifizierte (dynamische) SQL's nur hier gesucht, egal ob Naming auf *SQL oder *SYS steht.
In der "Classic/Native"-AS/400-Umgebung gibt es dies schon mit dem Konzept der CURLIB. Warum wird mit der DFTRDBCOL nicht auch die CURLIB des SQL-Serverjobs QZDAxxINIT gesetzt.
Im JOB selbst kann ich (zumindest mit WRKJOB) nicht erkennen, ob eine DFTRDBCOL gesetzt ist oder nicht.
Denn die erste Lib im USR-Teil der LIBL muß nicht zwingend auch die DFTRDBCOL sein.
Sven
@Sven
Die CURLIB ist leider keine Definition für SQL.
Nun muss man bei den Serverjobs auch noch sehen, dass diese originär unter dem User QUSER laufen. Dieser sollte daher auch keine CURLIB haben.
DFTRDBCOL ist eine SQL-Spezifikation und ausschließlich Anwendungsabhängig.
Durch entsprechende Optionen zur COMPILE-Zeit bestimme ich die Verwendung mittels "SET OPTION ..." bzw. bei den CRTSQLxxx-Befehlen.
Für dynamische SQL's (wie bei REXX oder SQLCLI und halt auch ODBC) kann ich dies dann zur Laufzeit bestimmen.
Anmerkung: Warum sollte IBM nicht auch mal Fehler beheben ?
Hier habe ich noch einmal eine sehr schöne Beschreibung für die Namensauflösung:
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/db2/rbafzmst39.htm#HDRQUALUN
und blättere dann zum Kapitel:
Qualification of Unqualified Object Names