Datenübernahme DB2/400 --> SQL Server

[calu]

Hallo NG,

hat einer von Euch Erfahrung bei der Datenübernahme von DB2 (auf iSeries)
zum MS SQL Server 2000 ?

Insbesondere, was den Import der Logischen Files angeht. Der DTS erkennt die
LFŽs nur ohne Keys. Und das ist falsch.
Komischerweise erkennt Visio beim "reverse Engineering" per ODBC die LFŽs
samt Indizes...
Also muss es irgendeine Möglichekit geben..

Danke für Eure Hilfe

Gruß Carsten

[Christa Kurschat]

Hallo calu,

Post by calu
Hallo NG,
hat einer von Euch Erfahrung bei der Datenübernahme von DB2
(auf iSeries) zum MS SQL Server 2000 ?
Insbesondere, was den Import der Logischen Files angeht. Der
DTS erkennt die LFŽs nur ohne Keys. Und das ist falsch.
Komischerweise erkennt Visio beim "reverse Engineering" per
ODBC die LFŽs samt Indizes...
Also muss es irgendeine Möglichekit geben..

wie versuchst Du per DTS zu importieren?
IMHO gibt's beim DTS nicht die Möglichkeit, mehr als die bloßen
Datenstrukturen zu übernehmen. Die erkennt DTS durch analysieren der ersten
100(?) DS.

Objekte kannst Du nur zwischen SQL servern im-und exportieren.
Es bleibt Dir wohl keine andere Möglichkeit, als die Keys und Indizes
nachträglich per Hand auf dem SQL Server zu erstellen.

Oder, ich weiß aber nicht genau, ob das geht, die Create-Anweisungen im DB2
erstellen zu lassen und diese im SQL Server auszuführen.

Gruß
Christa

[calu]

Hallo Christa,
danke für Deine Antwort.
Die Keys von Hand nachzutragen dauert zu lange. sind etwa 1000 Tabellen.
Aus der DB2 mit dem "create"-Befehl geht es auch nicht, weil er bei den
Views (LFŽsŽ auf der iSeries) ebenfalls keine Keys erzeugt.
Ich habe inzwischen herausgefunden, warum Visio die Indizes anzeigen kann.
Visio nutzt eine spezielle ODBC-API.
Das ist aber nicht in meinem Sinne...

Gruß Carsten

Post by Christa Kurschat
Hallo calu,

Post by calu
Hallo NG,
hat einer von Euch Erfahrung bei der Datenübernahme von DB2
(auf iSeries) zum MS SQL Server 2000 ?
Insbesondere, was den Import der Logischen Files angeht. Der
DTS erkennt die LFŽs nur ohne Keys. Und das ist falsch.
Komischerweise erkennt Visio beim "reverse Engineering" per
ODBC die LFŽs samt Indizes...
Also muss es irgendeine Möglichekit geben..

wie versuchst Du per DTS zu importieren?
IMHO gibt's beim DTS nicht die Möglichkeit, mehr als die bloßen
Datenstrukturen zu übernehmen. Die erkennt DTS durch analysieren der ersten
100(?) DS.
Objekte kannst Du nur zwischen SQL servern im-und exportieren.
Es bleibt Dir wohl keine andere Möglichkeit, als die Keys und Indizes
nachträglich per Hand auf dem SQL Server zu erstellen.
Oder, ich weiß aber nicht genau, ob das geht, die Create-Anweisungen im DB2
erstellen zu lassen und diese im SQL Server auszuführen.
Gruß
Christa
--
Access-FAQ: http://www.donkarl.com
SQL-Server-FAQ: www.sqlfaq.de
auch interessant: http://www.insidesql.de
http://groups.google.de/advanced_group_search?hl=de&lr=&ie=UTF-8

[Elmar Boye]

Hallo Carsten,

Post by calu

Post by Christa Kurschat

Post by calu
hat einer von Euch Erfahrung bei der Datenübernahme von DB2
(auf iSeries) zum MS SQL Server 2000 ?
Insbesondere, was den Import der Logischen Files angeht. Der
DTS erkennt die LFŽs nur ohne Keys. Und das ist falsch.
Komischerweise erkennt Visio beim "reverse Engineering" per
ODBC die LFŽs samt Indizes...

wie versuchst Du per DTS zu importieren?
IMHO gibt's beim DTS nicht die Möglichkeit, mehr als die bloßen
Datenstrukturen zu übernehmen. Die erkennt DTS durch analysieren der
ersten 100(?) DS.

Bei konkreten Datenquellen nutzt es schon das Ole DB API,
wie es auch über ADO OpenSchema zur Verfügung steht.
Geraten wird nur bei Textdatenquellen, wo kein Datentyp
zur Verfügung steht.

Post by calu
Die Keys von Hand nachzutragen dauert zu lange. sind etwa 1000
Tabellen. Aus der DB2 mit dem "create"-Befehl geht es auch nicht,
weil er bei den Views (LFŽsŽ auf der iSeries) ebenfalls keine Keys
erzeugt.
Ich habe inzwischen herausgefunden, warum Visio die Indizes anzeigen
kann. Visio nutzt eine spezielle ODBC-API.

An die Informationen käme DTS ebenfalls ran, nur versucht es das
gar nicht. Als Migrationstool ist eben nie gedacht gewesen.

Allerdings kannst Du gleiches wie Visio auf verschiedenen Wegen machen.
Einmal über einen Verbindungsserver und damit verbundene Prozeduren
wie sp_tables_ex, sp_columns_ex, sp_primarykeys - schau dazu
mal in die SQL Server Dokumentation.

Oder auch über ADO - wäre bei DTS als Active-X Script einzubinden,
in dem Du Dir die Daten über die OpenSchema Methode holst

Und in beiden Fällen entweder das komplette CREATE TABLE selbst
machst oder aber nur Primärschlüssel nachpflegst.

Konkrete Beispiele zur AS400 kann ich Dir nicht liefern, bestenfalls
http://groups-beta.google.com/group/microsoft.public.de.sqlserver/browse_frm/thread/f0c2a72da6184c8f/703a08c84c01666e?lnk=st&q=OpenSchema++author:Elmar+author:Boye&rnum=6&hl=en#703a08c84c01666e

Aber Google spuckt das eine oder andere dazu aus.

Was die Sichten angeht: Das ist zunächst mal nur eine SQL Anweisung.
Wovon DTS u. a. nur die Inhalte sehen.
Und wenn Du die Basistabellen ohnehin importierst, solltest Du
eher die Sichten im SQL Server neu anlegen. Was nach genutztem
Funktions-Umfang ein Umschreiben an der einen oder anderen Stelle
erfordert.

Gruss
Elmar

[Christoph Muthmann]

Elmar Boye wrote:
[snip]

Hallo Carsten,
ich hänge mich einfach mal dran. Bzgl. Anbindung empfehle ich immer den
Treiber von Hit. Siehe hierzu auch:
http://snipurl.com/gu9n

Für die Migration von Objekten verwende ich immer Erwin von CA.
Allerdings aufgepasst bei Objekten (vor allem *LF) die auf der iseries
mit DDS angelegt wurden. Diese entsprechen unter Umständen nicht den
SQL-Konventionen und können nicht so einfach konvertiert werden. (Zum
Beispiel Select- und Ommit-Klauseln)

Hier muss man dann versuchen über den Systemkatalog oder entsprechende
Routinen zu gehen:
DSPFD FILE(mylib/mylogicalfile)
TYPE(*ACCPTH)

Das ganze in eine Datei umleiten und per Programm auswerten und SQLs
generieren.

Einen schönen Tag noch,
Christoph

[CaLu]

Hallo Christoph,

vielen Dank für den Tipp.
Das TYPE(*ACCPTH) im dpsfd war ein wichtiger Hinweis.
Wenn ichmir die ausgegebene Datei mit SQL ansehe, stehen da auch eigentlich
die notwendigen Informationen. Jetzt muss ich nur eine Möglichkeit finden,
das automatisiert auszuwerten.
Du hast von Programmen dafür gesprochen, meintest Du etwas schon vorhandenes
?
Irgendwie muss ich diese Information ja auch auf den SQL-Server bekomen...

Viele Grüße

Carsten

Post by Christoph Muthmann
[snip]
Hallo Carsten,
ich hänge mich einfach mal dran. Bzgl. Anbindung empfehle ich immer den
http://snipurl.com/gu9n
Für die Migration von Objekten verwende ich immer Erwin von CA.
Allerdings aufgepasst bei Objekten (vor allem *LF) die auf der iseries
mit DDS angelegt wurden. Diese entsprechen unter Umständen nicht den
SQL-Konventionen und können nicht so einfach konvertiert werden. (Zum
Beispiel Select- und Ommit-Klauseln)
Hier muss man dann versuchen über den Systemkatalog oder entsprechende
DSPFD FILE(mylib/mylogicalfile)
TYPE(*ACCPTH)
Das ganze in eine Datei umleiten und per Programm auswerten und SQLs
generieren.
Einen schönen Tag noch,
Christoph
--
(Please post ALL replies to the newsgroup only unless indicated
otherwise)

[Christoph Muthmann]

Post by CaLu
Hallo Christoph,
vielen Dank für den Tipp.
Das TYPE(*ACCPTH) im dpsfd war ein wichtiger Hinweis.
Wenn ichmir die ausgegebene Datei mit SQL ansehe, stehen da auch
eigentlich die notwendigen Informationen. Jetzt muss ich nur eine
Möglichkeit finden, das automatisiert auszuwerten.
Du hast von Programmen dafür gesprochen, meintest Du etwas schon
vorhandenes ?
Irgendwie muss ich diese Information ja auch auf den SQL-Server bekomen...

Hallo Carsten,
da ich keine CL-Leuchte bin, habe ich reichlich rumgetrickst. Den Weg
möchte ich Dir aus heutiger Sicht nicht mehr beschreiben.

Ich würde jetzt diese Tabelle einfach auf den SQLServer übertragen und
dort mit T-SQL auswerten!

Ich kann Dir also leider nichts anbieten! ;-(
Aber aus einer Feldliste sollte sich doch einfach ein CREATE INDEX
generieren lassen, oder?

Einen schönen Tag noch,
Christoph

[CaLu]

Hallo Christoph,

das ist richtig, so machen wir das jetzt auch. Entscheidend war auf jeden
Fall der Tipp mit dem *ACCPTH

Danke und Gruß Carsten

Post by Elmar Boye

Post by CaLu
Hallo Christoph,
vielen Dank für den Tipp.
Das TYPE(*ACCPTH) im dpsfd war ein wichtiger Hinweis.
Wenn ichmir die ausgegebene Datei mit SQL ansehe, stehen da auch
eigentlich die notwendigen Informationen. Jetzt muss ich nur eine
Möglichkeit finden, das automatisiert auszuwerten.
Du hast von Programmen dafür gesprochen, meintest Du etwas schon
vorhandenes ?
Irgendwie muss ich diese Information ja auch auf den SQL-Server bekomen...

Hallo Carsten,
da ich keine CL-Leuchte bin, habe ich reichlich rumgetrickst. Den Weg
möchte ich Dir aus heutiger Sicht nicht mehr beschreiben.
Ich würde jetzt diese Tabelle einfach auf den SQLServer übertragen und
dort mit T-SQL auswerten!
Ich kann Dir also leider nichts anbieten! ;-(
Aber aus einer Feldliste sollte sich doch einfach ein CREATE INDEX
generieren lassen, oder?
Einen schönen Tag noch,
Christoph
--
(Please post ALL replies to the newsgroup only unless indicated
otherwise)

[d***@hotmail.com]

Carsten,

Have a look at StarQuest Data Replicator:
http://www.starquest.com/Productfolder/infoSQDR.html

It support incremental replication (iie it will copy only the data that
has changed).

Bob