DDS zu SQL konvertieren, generieren o.ä.

[ibmnewbie]

Hallo!

Ein newbie hat ne Frage an die Cracks, die sich hier tummeln:

Welche Möglichkeiten gibt es, um (relativ alte) DDS-Definitionen einer grossen Zahl von physical files automatisch in SQL umzuwandeln, weil man die SQL Statements beispielsweise für gleichartige Tabellen in anderen RDBMs braucht?

Vielen Dank im Voraus,
das newbie

[Fuerchau]

Das kann nur der OpsNav automatisiert.

[B.Hauser]

iSeries Navigator Database

Datenbanken
Schema (=Bibliothek) auswählen
Innerhalb des Schemas Tabellen (=physische Dateien) öffnen, Tabellen auswählen, Rechtsclick, SQL generieren und generierte SQL-Statements prüfen.

Was nicht nach SQL konvertiert werden kann wird im Skript als Text mit Fehlermeldung ausgegeben.

Birgitta

[ibmnewbie]

Das kann nur der OpsNav automatisiert.

und für einen Anfänger zum mitschreiben: was ist OpsNav?

Danke

[Fuerchau]

Das ist die Abkürzung für den CA OperationsNavigator.

[UFK]

Das kann nur der OpsNav automatisiert.

Hm, klar kann (und sollte) man dafür den OperationsNavigator der i-Series einsetzen, aber genau genommen ist das ("Das kann nur der OpsNav automatisiert") so nicht wahr.

Ich habe mir selber schon lange vor dem Erscheinen des OpsNav ein CL oder REXX dafür geschrieben, um DDS aus Source-Dateien in universelle SQL-Befehle zu konvertieren. Und das kann natürlich auch jeder andere Programmierer selbst realisieren.

Außerdem verwendet der OpsNav mit Sicherheit nicht die DDS-Definitionen (wörtlich), sondern liest die Beschreibung aus den aktuell in der Datenbank vorhandenen Dateien (Tabellen) ein. Nun ja, das dürfte ja auch den Zweck erfüllen, soweit das System nicht auch noch temporäre Dateien verwendet, die es dann gemäß einer gespeicherten DDS erstellen würde, die man evtl. aber kaum vorfinden kann, da sie in der QTEMP stehen ...

Man kann auch Probleme mit Serien von Dateien bekommen, die alle die gleiche Struktur bzw. DDS haben, die aber unterschiedliche Namen haben. In der AS400 hätte man das dann auch besser in Teildateien speichern können, die für SQL aber noch ein weiteres Problem darstellen würden, da SQL das so nicht kennt ...

Ein weiteres Thema ist oft der Dump des gesamten Inhalts einer ganzen DB2/400-Datenbank, um sie in eine andere SQL-Datenbank zu übertragen. Ich glaube, OpsNav fehlt die simple praktische SQL-Dump-Funktion noch, oder ?

Wer MySQL benutzen will, wird sich so etwas wie DUMP & LOAD aber wünschen, denn eine direkte SQL-Verbindung per DRDA können die DB2/400 und MySQL wohl noch nicht etablieren, oder ?

PS: Eine Dump-Routine für alle Tabellen kann man natürlich auch selber schreiben, wenn es wirklich noch fehlen sollte. Incl. Teildateien, wenn's sein muß ...

[Fuerchau]

Was ist DUMP & LOAD denn anderes als SAV und RST ?
Soweit ich weiß, unterstützt der OpsNav auch das Sichern und Wiederherstellen per SAVF's. Zusätzlich gibts ja auch noch die gemeinsame Maintenance-Funktion mehrerer Systeme um eben genau diese Dinge (Abgleich, Objektverteilung) zu realisieren.

Auch andere DB's kennen Sicherungsbefehle und nennen das dann Backup, das halte ich nicht für einen Vergleich.

Der Hinweis auf den OpsNav erfolgt ja nur um eben nicht erst selber was programmieren zu müssen.

Natürlich kann jeder für seine spezifischen Belange auch selber etwas programmieren, aber darum ging es bei diesem Thema ja nicht.

Sondern um bereits vorhandenes.

Du kannst gerne deine Quellen veröffentlichen um anderen die Arbeit zu erleichtern. Schließlich wird dann ja auch auf etwas "vorhandenes" zurückgegriffen.

[ibmnewbie]

iSeries Navigator Database

Datenbanken
Schema (=Bibliothek) auswählen Innerhalb des Schemas Tabellen (=physische Dateien) öffnen, Tabellen auswählen, Rechtsclick, SQL generieren und generierte SQL-Statements prüfen.

Was nicht nach SQL konvertiert werden kann wird im Skript als Text mit Fehlermeldung ausgegeben.

Birgitta

Vielen Herzlichen Dank!!!
Ich hab zwar ne Weile gebraucht aber es funzt!

Bis auf eine Kleinigkeit, die alles ausbremst: Das generierte SQL (ANSI/ISO) scheint einen Bug zu haben:
Es werden die Default-Klausel und die Not-Null-Klausel der Spalten vertauscht und das versteht die Oracle DB nicht.
Bestimmt ist dieses Problem altbekannt bei euch Experten, oder?

Danke im Voraus
das ibm newbie

[Fuerchau]

Eher nicht.
Es kann einfach sein, dass die Oracle halt den DB2-SQL nicht versteht.

Läßt du die generierten SQL's auf eine DB/2 los, versteht diese die.

Also kein BUG sondern Kompatibilitätsprobleme.

[ibmnewbie]

Heisst das, durch die Blume gesagt, dass DB/2 nicht vollständig ANSI-Standard-kompatibel ist?

[Fuerchau]

Das könnte eher für Oracle zutreffen.
Schließlich hat jede DB ihre Eigenheiten (genannt Erweiterungen) die jeweils andere DB's nicht kennen.

Wenn ich von Oracle SQL's bekomme, muss ich diese auch erst mal bearbeiten. Insbesonders was die Feldtypen angeht (VARCHAR2->VARCHAR oder GRAPHIC CCSID 13488) u.ä.

[BenderD]

Hallo,

Erstellungsskripten sind oft nicht vollständig übertragbar, da keine einzige Datenbank Implementierung Referenz Implementierung für ANSI SQL darstellt. In jeder Datenbank gibt es momentan (leider) Abweichungen nach beiden Richtungen; entweder wird ein ANSI level nicht vollständig implementiert (wenn dann die Quelle so ein Feature benutzt und die Zieldatenbank kanns nicht, dann knallts) oder es werden von der Quelldatenbank zusätzliche proprietäre Erweiterungen benutzt (dann erfüllt diese DB sogar 100% ANSI) und dann knallts ion jeder Zieldatenbank, die diese Erweiterung so nicht hat.
Ohne alle Blumen: sowohl Oracle als auch DB2 sind nicht 100% ANSI konform (DB2 auf der /400 hinkt eh ein wenig hinterher!)
Mit Spielzeug wie Ooops Nerv ist das nicht lösbar (da kommt auch manchmal Quatsch raus, den die eigene DB nicht versteht), da braucht man richtiges Werkzeug, das mit beiden Datenbanken kann, das sollte dann eher dazu in der Lage sein die erforderlichen Anpassungen vorzunehmen (ErWin wäre da eventuell Kandidat).

mfg

Dieter Bender

Heisst das, durch die Blume gesagt, dass DB/2 nicht vollständig ANSI-Standard-kompatibel ist?