5
SQL 2005 automatisches Befüllen einer DB
Hallo,
ich möchte in unregelmäßigen Abständen Daten aus verschiedenen Datenbank auf unseren MS SQL Server 2005 SP2 laden. Da die Daten nicht immer aus der Microsoft SQL Server Welt stammen, kann ich auch nicht immer den Transfer SQL Server Object Task verwenden. Idealerweise möchte ich das ganze per ODBC Connect zu den einzelnen Datenbanken versuchen, komme aber mit keiner Standardlösung zurande.
Hat jemand bzw. kennt jemand eine Lösung zu dieser Problematik?
Gruß InShaDan
ich möchte in unregelmäßigen Abständen Daten aus verschiedenen Datenbank auf unseren MS SQL Server 2005 SP2 laden. Da die Daten nicht immer aus der Microsoft SQL Server Welt stammen, kann ich auch nicht immer den Transfer SQL Server Object Task verwenden. Idealerweise möchte ich das ganze per ODBC Connect zu den einzelnen Datenbanken versuchen, komme aber mit keiner Standardlösung zurande.
Hat jemand bzw. kennt jemand eine Lösung zu dieser Problematik?
Gruß InShaDan
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 79542
Url: https://administrator.de/forum/sql-2005-automatisches-befuellen-einer-db-79542.html
Ausgedruckt am: 23.12.2024 um 01:12 Uhr
5 Kommentare
Neuester Kommentar
Moin InShaDan,
ich verschiebe erstmal diesen Beitrag nach "Datenbanken".
Ansonsten fürchte ich, mit der Anforderung...
Und WTF soll "Gibt es eine Standard-Lösung für ODBC-Connect?" heißen??? Das habe ich viermal gelesen und doppelt so oft nicht verstanden.
Grüße
Biber
ich verschiebe erstmal diesen Beitrag nach "Datenbanken".
Ansonsten fürchte ich, mit der Anforderung...
ich möchte in unregelmäßigen Abständen Daten aus verschiedenen Datenbank [....] . laden..
..ist eigentlich noch ganz die erforderliche Lastenheftqualität erreicht, die zu einer zügigen Budgetfreigabe für dieses Projekt führen könnte.Und WTF soll "Gibt es eine Standard-Lösung für ODBC-Connect?" heißen??? Das habe ich viermal gelesen und doppelt so oft nicht verstanden.
Grüße
Biber
Also folgende Fakten:
es existieren insgesamt 9 verschiedene Datenbanken Systeme (DB2, MySQL etc.) aus denen verschiedene Tabellen (bzw. Teile davon) auf den MS SQL 2005 Server kopiert werden sollen. Ich habe hier schon verschiedene Szenarien mit der SQL Server Business Inteligence duchgespielt, kam aber leider nicht zu dem gewünschten Ergebniss.
Ziel der ganzen Aktion soll es sein, in eine leere Datenbank die einzelnen Tabelle
a) zu erstellen (per SQL-Skipt)
b) nach erfolgreichem Erstellen der Tabellen diese zu befüllen
Ich dachte hierbei an eine Lösung mit ODBC Verbindungen, die ich aber so nicht im Transfer SQL Server Object Task nicht verwenden kann. Auch fällt mit ad-hoc keine Lösung ein um das ganze per Data Flow Task zu erledigen.
Schätzungsweise hängt das mitunter auch daran, dass ich mich jetzt auf diese beiden Möglichkeiten versteift habe. Daher meine Frage ob jemand einen anderen Ansatz kennt oder vielleicht auch eine Lösunf parat hat.
Gruß
InShaDan
es existieren insgesamt 9 verschiedene Datenbanken Systeme (DB2, MySQL etc.) aus denen verschiedene Tabellen (bzw. Teile davon) auf den MS SQL 2005 Server kopiert werden sollen. Ich habe hier schon verschiedene Szenarien mit der SQL Server Business Inteligence duchgespielt, kam aber leider nicht zu dem gewünschten Ergebniss.
Ziel der ganzen Aktion soll es sein, in eine leere Datenbank die einzelnen Tabelle
a) zu erstellen (per SQL-Skipt)
b) nach erfolgreichem Erstellen der Tabellen diese zu befüllen
Ich dachte hierbei an eine Lösung mit ODBC Verbindungen, die ich aber so nicht im Transfer SQL Server Object Task nicht verwenden kann. Auch fällt mit ad-hoc keine Lösung ein um das ganze per Data Flow Task zu erledigen.
Schätzungsweise hängt das mitunter auch daran, dass ich mich jetzt auf diese beiden Möglichkeiten versteift habe. Daher meine Frage ob jemand einen anderen Ansatz kennt oder vielleicht auch eine Lösunf parat hat.
Gruß
InShaDan
Hallo InShaDan
es geht. im alten SQL Server waren es die DTS-Packages die man dafür benutzt hat und im 2005 sind es die DTS-x packages. Diese musst du dann dementsprechend Programmieren.
Um dir das hier alles zu erklären würde der Platz nciht reichen. Schaue dir mal in deiner Doku ( ich gehe mal davon aus das du die hast, da ihr ja in der Frma den SQL 2005 nutzt )
zum SSIS an. Dort ist es beschrieben und auch mit Screenshots zum SSIS Studio. Die Vorgehensweise ist komplett anders als beim SQL 2000. Deswegen ist es auch schlecht parallelen zu ziehen.
Auch um die Frage evtl vorne weg zu beantworten. Es ist nicht ohne weiteres möglich DTS-POackages vom SQL2000 nach SQL2005 zu portieren.
Andere alternative wäre hinzugehen und per vba oder vb6 oder vb.net die Tabellenstrukturen auszulesen und dann neu anzulegen. Danach dann den Kopiervorgang starten. Dann hättest du aber eine Serverunabhängige Lösung, die nicht mit Boardmitteln des SQL2005 gelöst wurden.
Gruß
Sven
es geht. im alten SQL Server waren es die DTS-Packages die man dafür benutzt hat und im 2005 sind es die DTS-x packages. Diese musst du dann dementsprechend Programmieren.
Um dir das hier alles zu erklären würde der Platz nciht reichen. Schaue dir mal in deiner Doku ( ich gehe mal davon aus das du die hast, da ihr ja in der Frma den SQL 2005 nutzt )
zum SSIS an. Dort ist es beschrieben und auch mit Screenshots zum SSIS Studio. Die Vorgehensweise ist komplett anders als beim SQL 2000. Deswegen ist es auch schlecht parallelen zu ziehen.
Auch um die Frage evtl vorne weg zu beantworten. Es ist nicht ohne weiteres möglich DTS-POackages vom SQL2000 nach SQL2005 zu portieren.
Andere alternative wäre hinzugehen und per vba oder vb6 oder vb.net die Tabellenstrukturen auszulesen und dann neu anzulegen. Danach dann den Kopiervorgang starten. Dann hättest du aber eine Serverunabhängige Lösung, die nicht mit Boardmitteln des SQL2005 gelöst wurden.
Gruß
Sven
es geht. im alten SQL Server waren es die
DTS-Packages die man dafür benutzt hat
und im 2005 sind es die DTS-x packages. Diese
musst du dann dementsprechend Programmieren.
An diesen DTSX Paketen sitze ich ja gerade. ich habe aber das gefühl hier ziehmlich Eingleis stur in eine richtung zu laufen. ich erstelle eine Data Flow Task und geben hier den DataReader Source an... DataReaderDestionation ist kein Problem, denn es jhandelt sich ja hierbei um die ZieldatenbankDTS-Packages die man dafür benutzt hat
und im 2005 sind es die DTS-x packages. Diese
musst du dann dementsprechend Programmieren.
Um dir das hier alles zu erklären
würde der Platz nciht reichen. Schaue
dir mal in deiner Doku ( ich gehe mal davon
aus das du die hast, da ihr ja in der Frma
den SQL 2005 nutzt )
zum SSIS an. Dort ist es beschrieben und
auch mit Screenshots zum SSIS Studio. Die
Vorgehensweise ist komplett anders als beim
SQL 2000. Deswegen ist es auch schlecht
parallelen zu ziehen.
Hm, wie Üblich... IRGENDWO!!!würde der Platz nciht reichen. Schaue
dir mal in deiner Doku ( ich gehe mal davon
aus das du die hast, da ihr ja in der Frma
den SQL 2005 nutzt )
zum SSIS an. Dort ist es beschrieben und
auch mit Screenshots zum SSIS Studio. Die
Vorgehensweise ist komplett anders als beim
SQL 2000. Deswegen ist es auch schlecht
parallelen zu ziehen.
Auch um die Frage evtl vorne weg zu
beantworten. Es ist nicht ohne weiteres
möglich DTS-POackages vom SQL2000 nach
SQL2005 zu portieren.
Das ist mir bekannt, zudem müssten dann je ersteinmal welche im 2000er DTS Format vorliegen, tun sie aber nicht...beantworten. Es ist nicht ohne weiteres
möglich DTS-POackages vom SQL2000 nach
SQL2005 zu portieren.
Andere alternative wäre hinzugehen und
per vba oder vb6 oder vb.net die
Tabellenstrukturen auszulesen und dann neu
anzulegen. Danach dann den Kopiervorgang
starten. Dann hättest du aber eine
Serverunabhängige Lösung, die nicht
mit Boardmitteln des SQL2005 gelöst
wurden.
Wäer aber flexibel, da es sich ja um verschiedene Quellsysteme handelt.per vba oder vb6 oder vb.net die
Tabellenstrukturen auszulesen und dann neu
anzulegen. Danach dann den Kopiervorgang
starten. Dann hättest du aber eine
Serverunabhängige Lösung, die nicht
mit Boardmitteln des SQL2005 gelöst
wurden.
Moin InShaDan,
grundsätzlich hört sich Deine Anforderung aber schon an wie der erste Kristallisationspunkt eines entstehenden Datawarehouse.
Und in diesem Fall wäre es auch mit besseren Datenbankblechen (z.B. Oracle oder DB2) eher die Ausnahmestrategie, dass mit den BI-Instrumenten des Zielsystems abzufackeln.
In der Regel werden diese ETL-Prozesse dann mit einem Tool gemacht, dass
a) etwas davon versteht und
b) ALLE gängigen DB-Formate von 1988-2008 versteht + Flatfiles + 100 andere Fremdformate
c) und eben auch Prozesse steuern/automatisieren kann
Ich würde Dir empfehlen, mal eine der gängigen Suchmaschinen zu befragen und empfehle als Suchwort-Liste "DWH ETL-Prozesse Datenbefüllung" ( oder gleich "Informatica PowerCenter"
).
Mit (DB-)herstellerabhängigen Tools habe ich keine guten Erfahrungen gemacht.
Grüße
Biber
grundsätzlich hört sich Deine Anforderung aber schon an wie der erste Kristallisationspunkt eines entstehenden Datawarehouse.
Und in diesem Fall wäre es auch mit besseren Datenbankblechen (z.B. Oracle oder DB2) eher die Ausnahmestrategie, dass mit den BI-Instrumenten des Zielsystems abzufackeln.
In der Regel werden diese ETL-Prozesse dann mit einem Tool gemacht, dass
a) etwas davon versteht und
b) ALLE gängigen DB-Formate von 1988-2008 versteht + Flatfiles + 100 andere Fremdformate
c) und eben auch Prozesse steuern/automatisieren kann
Ich würde Dir empfehlen, mal eine der gängigen Suchmaschinen zu befragen und empfehle als Suchwort-Liste "DWH ETL-Prozesse Datenbefüllung" ( oder gleich "Informatica PowerCenter"
).Mit (DB-)herstellerabhängigen Tools habe ich keine guten Erfahrungen gemacht.
Grüße
Biber
