ODBC und Bibliotheksliste

[hs]

Hallo Programmierprofis,

wir haben heute zwei AS400 - ein Livesystem und ein Testsystem, auf dem sich eine Kopie der Daten befindet.

Daran angeschlossen haben wir über ODBC diverse Applikationen, Access aber auch SQL2000-DTS und SQL2008 SSIS-Pakete, die Daten transferieren.

Ein Switch von Live - auf Testsystem ist einfach herbeizuführen, da man einfach nur die ODBC-Verbindung bzw. IP-Adresse ändern muss. Der Rest (Bibliotheksnamen) ist identisch auf beiden System.

Wir wollen das Testsystem nun durch eine Testumgebung auf dem Produktivsystem ablösen.

D.h. Die Live-Bibliotheken werden als Kopie auf dem gleichen System sein, das Testsystem soll entfallen.

Leider ist uns keine einfache Möglichkeit bekannt, jetzt von der Live- in die Produktivumgebung zu wechseln - von den externen Systemen (ODBC) aus.

Nach unserem Kenntnisstand muss man z.B. bei einem SQL-Kommando in DTS auf dem SQL2000-Server immer explizit den Bibliotheksnamen mitgeben.
Z.B. select * from mybib.mytab where...

mybib heißt aber jetzt mybib2, wenn ich auf die Testumgebung wechseln möchte.

Schön wäre es, wenn man einfach nur select * from mytab angeben könnte und die gerade aktuelle Bibliothek anderweitig festlegt. Es gibt dafür ja z.B. eine Bibliotheksliste in der ODBC-Verbindung.

Das funktionierte aber nicht. Obwohl ich dort MYBIB eingetragen hatte, funktioniert der Befehl select * from mytab nicht.

Machen wir was falsch oder gibt es eine andere (einfache!) Lösung.

Natürlich könnte man z.B. in DTS auch mit Parametern arbeiten und darüber den Bibiotheksnamen mitgeben, aber das wäre schon sehr aufwendig.

Vielen Dank für eure Antworten
HS

[B.Hauser]

Es reicht nicht in der ODBC-Verbindung die Bibliotheksliste anzugeben.
Es darf kein Default Schema/Library gesetzt werden und außerdem muss System-Naming verwendet werden.
Bei SQL Naming kann unqualifiziert nur auf eine einzige Bibliothek (Default-Schema) zugegriffen werden. Die Bibliotheksliste wird immer ignoriert.
Die Bibliotheksliste wird auch ignoriert, wenn man mit System-Naming arbeitet und ein Default-Schema gesetzt hat.

Birgitta

[hs]

Danke für die Info.

D.h. es gibt dann wohl keine Möglichkeit, denn unsere ERP-System arbeitet - wie vermutlich die meisten - mit mehreren Bibiotheken

[Fuerchau]

Ich würde dennoch mit SQL-Naming und Schema arbeiten.
Für Echt und Testsystem je eine eigene Lib erstellen, die ausschließlich Views (LF's) auf die jeweiligen PF-Dateien enthalten.
Die Views enthalten halt den Verweis auf die jeweils echte Bibliothek.

Zum Wechsel des Zielsystems dann einfach das Schema setzen und alle SQL's unqualifiziert über das Schema abgreifen.

Eine VIEW, die kein Join ist kann per SQL auch upgedatet werden.

[hs]

Bei mehreren Tausend Objekten wäre das aber eine Sträflingsarbeit (auch wenn sicher nicht alle benötigt werden).

Grundsätzlich ist das aber schon eine Möglichkeit, über die wir mal nachdenken werden.

Danke
HS

[Fuerchau]

Ich glaube nicht, dass es mehrere 1000 sind.
Du benötigst ja keine Indizes sondern ausschließlich die PF-Links.
SQL sucht sich seine Indizes sowieso selber.
Dies kannst du auch einfach per Script durchführen, in dem du für jede PF einer LIB einen create View durchführst.
Das ist doch schnell und ohne Aufwand gemacht.

[B.Hauser]

Also ich bin der Meninung, solange man sich ausschließlich auf der IBM i aufhält und mit Bibliothekslisten, Gruppen-Profilen und Berechtigungslisten arbeitet, sollte man NICHT auf SQL-Naming gehen.

PUnnkt und Strich aaustauschen ist eine Sache (die überigens seit dem letzten Technologie Refresh nicht mehr notwendig ist). Dass Objkjekte qualifiziert angegeben werden, wird man auf der IBM i selten finden, ebenso Anwendungen, die nur auf Tabellen/Physiche und logische Dateien, die in nur einer einzigen Biblitohek vorhanden sind, zugreifen. Sicher kann man dann kreuz und quer Views oder Aliases erstellt. (Ob man da noch den Überblick behält?)
Was aber noch viel schlimmer ist, SQL-Naming funktioniert, was Berechtigungen angheht anders als Sydtem Naming. Wird ein Datenbanken Objekt mit SQL-Naming erstellt wird die Public-Berechtigung grundsätzlich auf *EXCL gesezt.
Eigner wird entweder der Benutzer, der das Objekt erstellt hat, oder falls es ein Benutzer-Profil mit dem gleichen Namen wie die Bibliothek in der das Objekt erstellt wird, so wird dieses Benutzer-Profil der Eigner. Um solche Objekte ändern zu können ist eine SECADM Berechtigung an dem entsprechenden Benutzer-Profile erforderlich.

Birgitta

[KM]

@hs:
Warum machst Du es nicht einfach so wie Birgitta es vorgeschlagen hat (die ODBC-Verbindung auf System-Naming umstellen, die Default-Library entfernen und die Bibliotheksliste entsprechend anpassen)? Beim Umstellen auf die Testumgebung musst Du dann nur wieder die Bibiotheksliste ändern.
Oder habe ich hier etwas missverstanden?

Gruß,
KM

[Fuerchau]

Nun, was die Sicherheit angeht so ist gerade bei ODBC SQL-Naming die beste Lösung.
Es ist besser, bei falschen Zugriffen einen Fehler zu bekommen als auf das falsche Objekt zuzugreifen.
Es braucht ja nur mal jemand die Reihenfolge der Lib's zu tauschen oder der CHGLIBL des QZDA-Jobs schlägt fehl und man hat dann die Default QUSRLIBL im Zugriff. Da gibts auch keine Fehlermeldung!

Was neue Objekte (Table, Views) o.ä. angeht, so ist ja der APP-User bereits ausreichend diskutiert worden.
Zusätzlich benötige ich für meine eigenen Objekte kein *ALLOBJ o.ä., um anderen Berechtigungen per SQL-GRANT zu erteilen.