4
In mySQL-Trigger Daten aus Microsoft SQL (2000) abfragen?
Hallo zusammen,
ich habe hier in unser Warenwirtschafts-Datenbank unter mySQL Enterprise 5.1.50 in einer Tabelle einen Trigger laufen, der u.a. Daten aus einer Microsoft SQL 2000 - Datenbank auf einem anderen Server holen soll (über die gemeinsame Kundennummer), Google brachte mich nur zu Tipps für den umgekehrten Weg, also mySQL in MSSQL als "verbundenen Server" einzubinden.
a) geht das überhaupt?
b) wenn ja, dann auch in einem Trigger (Timeout-Probleme usw...)
Ansonsten müsste ich die Daten manuell aus MSSQL heraus und in mySQL hinein bringen (ggfs. Skripten, aber wie?)
Bin für jeden Tipp dankbar,
ein schönen Tag
Marcus
ich habe hier in unser Warenwirtschafts-Datenbank unter mySQL Enterprise 5.1.50 in einer Tabelle einen Trigger laufen, der u.a. Daten aus einer Microsoft SQL 2000 - Datenbank auf einem anderen Server holen soll (über die gemeinsame Kundennummer), Google brachte mich nur zu Tipps für den umgekehrten Weg, also mySQL in MSSQL als "verbundenen Server" einzubinden.
a) geht das überhaupt?
b) wenn ja, dann auch in einem Trigger (Timeout-Probleme usw...)
Ansonsten müsste ich die Daten manuell aus MSSQL heraus und in mySQL hinein bringen (ggfs. Skripten, aber wie?)
Bin für jeden Tipp dankbar,
ein schönen Tag
Marcus
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 214021
Url: https://administrator.de/contentid/214021
Printed on: April 25, 2024 at 02:04 o'clock
4 Comments
Latest comment
Hallo Marcus,
ob die Verbindung von MySQL zu SQL Server funktioniert kann ich Dir nicht sagen, eine kurze Suche bei Google läßt mich vermuten, daß das nicht so funktioniert. Wenn, dann müßte wohl im MySQL eine ODBC-Verbindung eingerichtet werden, aber ob das funktioniert ...?
Was allerdings geht, ist die Verbindung von SQL Server zu MySQL, das hast Du ja auch schon bei Google gefunden. Du könntest also die Tabellen, die Du aus SQL Server benötigst, in MySQL anlegen und per SQL-Server-Trigger aktualisieren. Der Trigger in MySQL kann dann auf diese Tabellenkopien zugreifen.
Ob diese Replikation dann allerdings zu längeren Verzögerungen oder gar Timeouts bei der Aktualisierung der Daten in SQL Server führen kann, das hängt wohl von Eurem Netzwerk und den Servern ab. Falls die Aktualisierung der Kopien in MySQL zu lange dauert, könnte man die SQL-Server-DB vielleicht erst noch mal auf dem selben Server replizieren, z.B. mittels Log Shipping, und erst auf dieser replizierten DB die Trigger für MySQL unterbringen. Die Daten wären zwar erst mit einer kleinen Zeitverzögerung in MySQL, aber das Problem einer Verzögerung oder eines Timeout bei der Bearbeitung der Daten wäre wohl gelöst.
Gruß, Mad Max
ob die Verbindung von MySQL zu SQL Server funktioniert kann ich Dir nicht sagen, eine kurze Suche bei Google läßt mich vermuten, daß das nicht so funktioniert. Wenn, dann müßte wohl im MySQL eine ODBC-Verbindung eingerichtet werden, aber ob das funktioniert ...?
Was allerdings geht, ist die Verbindung von SQL Server zu MySQL, das hast Du ja auch schon bei Google gefunden. Du könntest also die Tabellen, die Du aus SQL Server benötigst, in MySQL anlegen und per SQL-Server-Trigger aktualisieren. Der Trigger in MySQL kann dann auf diese Tabellenkopien zugreifen.
Ob diese Replikation dann allerdings zu längeren Verzögerungen oder gar Timeouts bei der Aktualisierung der Daten in SQL Server führen kann, das hängt wohl von Eurem Netzwerk und den Servern ab. Falls die Aktualisierung der Kopien in MySQL zu lange dauert, könnte man die SQL-Server-DB vielleicht erst noch mal auf dem selben Server replizieren, z.B. mittels Log Shipping, und erst auf dieser replizierten DB die Trigger für MySQL unterbringen. Die Daten wären zwar erst mit einer kleinen Zeitverzögerung in MySQL, aber das Problem einer Verzögerung oder eines Timeout bei der Bearbeitung der Daten wäre wohl gelöst.
Gruß, Mad Max
Hallo Mad Max,
interessante Ansätze, das mit dem Replizieren, muss ich mir mal durch den Kopf gehen lassen!
Erstmal vielen Dank für deine ausführlichen Gedanken zu dem Thema, prima, wie hier immer wieder geholfen wird
Schönen Tag noch
Marcus
interessante Ansätze, das mit dem Replizieren, muss ich mir mal durch den Kopf gehen lassen!
Erstmal vielen Dank für deine ausführlichen Gedanken zu dem Thema, prima, wie hier immer wieder geholfen wird
Schönen Tag noch
Marcus
Moin Marcus,
hab mir gerade nochmal durchgelesen, was ich heute nacht verzapft habe, war schon recht spät
Der erste Teil mit dem Rüberschieben der Daten von SQL Server zu MySQL, das ist ok. Aber der Teil mit der Replikation per Log Shipping auf dem selben Server ist Bullshit. Man kann es natürlich beliebig kompliziert gestalten.
Einfacher ist es natürlich, falls es zu Timeouts beim Schreiben der Kopien nach MySQL kommen sollte, einen Job einzurichten, der die Daten alle paar Minuten nach MySQL kopiert. Je nach Größe der SQL-Server-Tabellen kann das entweder komplett erfolgen oder es wird ein Zeitstempel in die Tabellen eingefügt (falls er nicht schon existiert) und nur die seit der letzten Übertragung aktualisierten DS werden in MySQL aktualisiert.
Gruß, Mad Max
hab mir gerade nochmal durchgelesen, was ich heute nacht verzapft habe, war schon recht spät
Der erste Teil mit dem Rüberschieben der Daten von SQL Server zu MySQL, das ist ok. Aber der Teil mit der Replikation per Log Shipping auf dem selben Server ist Bullshit. Man kann es natürlich beliebig kompliziert gestalten.
Einfacher ist es natürlich, falls es zu Timeouts beim Schreiben der Kopien nach MySQL kommen sollte, einen Job einzurichten, der die Daten alle paar Minuten nach MySQL kopiert. Je nach Größe der SQL-Server-Tabellen kann das entweder komplett erfolgen oder es wird ein Zeitstempel in die Tabellen eingefügt (falls er nicht schon existiert) und nur die seit der letzten Übertragung aktualisierten DS werden in MySQL aktualisiert.
Gruß, Mad Max
Moin Marcus und Mad Max,
zu der neueren Variante von Mad Max.
Es ist ja nicht nur diese (handwerklich lösbare) Problem der Weitermeldung der Aktualisierung der Daten von einer DB-instanz zur anderen.
Problem ist doch die "gemeinsam genutzte Kundennummer", die gleichermaßen in beiden System geändert werden könnte - das geht nicht bei asynchroner Verarbeitung.
Eines der Systeme muss "führend" sein bei Änderungen, sonst brauchst du keinen Trigger.
Andernfall bleibt nur der Abgleich der Änderungen in beiden Systemen an einem Nacht/Wochenendlauf mit manueller Entscheidung von Kollisionsbehandlungen.
Grüßr
Biber
zu der neueren Variante von Mad Max.
Es ist ja nicht nur diese (handwerklich lösbare) Problem der Weitermeldung der Aktualisierung der Daten von einer DB-instanz zur anderen.
Problem ist doch die "gemeinsam genutzte Kundennummer", die gleichermaßen in beiden System geändert werden könnte - das geht nicht bei asynchroner Verarbeitung.
Eines der Systeme muss "führend" sein bei Änderungen, sonst brauchst du keinen Trigger.
Andernfall bleibt nur der Abgleich der Änderungen in beiden Systemen an einem Nacht/Wochenendlauf mit manueller Entscheidung von Kollisionsbehandlungen.
Grüßr
Biber
