4
Import von MySQL DB Tabellen über ODBC-Connection
Hallo,
Ich habe folgendes Problem.
Und zwar greife Ich auf eine MySQL Datenbank via Access (über ODBC-Connection) zu. Die DB liegt auf einem entfernteren Server und ist deshalb bei den Abfragen (Hauptsächlich einige Formulare), die ich benötige sehr sehr langsam. Jetzt haben wir die Tabellen der DB einfach via Access Importiert und bei uns lokal auf dem Server abgelegt.
Damit ist dieses erste Problem gelöst.
Leider hab ich jetzt das Problem, wenn ich die aktuelleren Tabellen erneut importiere, werden neuere Einträge oder veränderte nicht in meinen lokalen Tabellen geändert sondern bleiben bestehen.
Der User-Login über den Ich auf die DB zugreife hat nur Leserechte und wir bekommen da auch keine anderen Rechte.
Wir wollten ursprünglich die Replikation der DB mit der Anleitung die hier im Forum beschrieben ist durchführen, da aber dies voraussetzt das wir die DB anhalten, ist das leider nicht möglich.
Desweiteren bin ich auf der Suche nach einer Möglichkeit den durchgeführten Import mit einem scheduled Task auszuführen. Damit dieser z.B.: immer nachts um 3 Uhr läuft und wir am morgen dann mit den aktuellen Tabellen arbeiten können.
Hat jemand dafür eine Lösung?
Danke schomal im voraus
mfg
Alex
Ich habe folgendes Problem.
Und zwar greife Ich auf eine MySQL Datenbank via Access (über ODBC-Connection) zu. Die DB liegt auf einem entfernteren Server und ist deshalb bei den Abfragen (Hauptsächlich einige Formulare), die ich benötige sehr sehr langsam. Jetzt haben wir die Tabellen der DB einfach via Access Importiert und bei uns lokal auf dem Server abgelegt.
Damit ist dieses erste Problem gelöst.
Leider hab ich jetzt das Problem, wenn ich die aktuelleren Tabellen erneut importiere, werden neuere Einträge oder veränderte nicht in meinen lokalen Tabellen geändert sondern bleiben bestehen.
Der User-Login über den Ich auf die DB zugreife hat nur Leserechte und wir bekommen da auch keine anderen Rechte.
Wir wollten ursprünglich die Replikation der DB mit der Anleitung die hier im Forum beschrieben ist durchführen, da aber dies voraussetzt das wir die DB anhalten, ist das leider nicht möglich.
Desweiteren bin ich auf der Suche nach einer Möglichkeit den durchgeführten Import mit einem scheduled Task auszuführen. Damit dieser z.B.: immer nachts um 3 Uhr läuft und wir am morgen dann mit den aktuellen Tabellen arbeiten können.
Hat jemand dafür eine Lösung?
Danke schomal im voraus
mfg
Alex
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: 151552
Url: https://administrator.de/contentid/151552
Printed on: April 25, 2024 at 13:04 o'clock
4 Comments
Latest comment
Moin,
magst du deine Zeilen nochmal in einen Buchstabensalat fassen, den die Nullen und Einzer auch verstehen?
Vorm löschen der Tabelle und reimportieren der Tabelle ins Access sei gewarnt - wenn die Datenmenge groß ist - dann muß danach auch eine komprimierung der DB stattfinden, sonst wächst die ins Bodenlose und Nebenwirkungen wie "die Sicherung dauert" " vorher via VPN ODBC war es schneller" usw. sind dir garantiert.
Gruß
magst du deine Zeilen nochmal in einen Buchstabensalat fassen, den die Nullen und Einzer auch verstehen?
Die DB liegt auf einem entfernteren Server
ist zwischen entfernt und lokal ein vpn?Damit dieser z.B.: immer nachts um 3 Uhr läuft und wir am morgen dann mit den aktuellen Tabellen arbeiten
Naja mag ja sein, dass die daten von 3 -8.05 aktuell sind, aber danach sind die alles andere als aktuell.Vorm löschen der Tabelle und reimportieren der Tabelle ins Access sei gewarnt - wenn die Datenmenge groß ist - dann muß danach auch eine komprimierung der DB stattfinden, sonst wächst die ins Bodenlose und Nebenwirkungen wie "die Sicherung dauert" " vorher via VPN ODBC war es schneller" usw. sind dir garantiert.
Gruß
Danke für die schnelle Antwort.
Die DB liegt auf einem Server im Firmen-Netzwerk (also Verbindung über LAN) nur der Server ist nicht an unserem Standort.
Das mit dem Aktuell ist eigtl. nicht so dramatisch, da wir über ein Webinterface in die DB schreiben können, und dann nur die Tabellen in der sich Daten geändert haben kopieren würden.
So wies aussieht benötigen wir hierfür dann immer ein Makro das erst unsere lokalen Tabellen löscht und dannach die neuen Tabellen vom 'entfernten' Server neu kopiert.
Das ist im moment unser erste Lösungsansatz. Dadurch vermeiden wir auch ein anwachsen der Datenmenge ins unendliche.
Gibts dafür evtl noch eine andere Lösung.
Gruß
Alex
Die DB liegt auf einem Server im Firmen-Netzwerk (also Verbindung über LAN) nur der Server ist nicht an unserem Standort.
Das mit dem Aktuell ist eigtl. nicht so dramatisch, da wir über ein Webinterface in die DB schreiben können, und dann nur die Tabellen in der sich Daten geändert haben kopieren würden.
So wies aussieht benötigen wir hierfür dann immer ein Makro das erst unsere lokalen Tabellen löscht und dannach die neuen Tabellen vom 'entfernten' Server neu kopiert.
Das ist im moment unser erste Lösungsansatz. Dadurch vermeiden wir auch ein anwachsen der Datenmenge ins unendliche.
Gibts dafür evtl noch eine andere Lösung.
Gruß
Alex
Moin,
du verstehst mich falsch...
Wenn du in einer Access DB eine einzelne große Tabelle löschst und dann wieder importierst...
An deiner Stelle - denn das umstellen von Accessintegrierten Tabellen zu verknüpften Mysql Tabellen macht man eigentlich wegen Speed und Ausfallsicherheit -
solltet Ihr mal mit dem Admin vor Ort (wo der Mysql Server steht) über MySQL Master Master Replication oder MySQL Master Slave Replication nachdenken.
Denn das ist dann auch eine Lösung, die diesen Namen verdient und kein Gefrickel
Gruß
du verstehst mich falsch...
Wenn du in einer Access DB eine einzelne große Tabelle löschst und dann wieder importierst...
- dann wächst die MDB - egal ob du haargenau die gleiche Tabelle mit identischem Inhalt reimportierst oder eine andere mit geändertem Inhalt.
An deiner Stelle - denn das umstellen von Accessintegrierten Tabellen zu verknüpften Mysql Tabellen macht man eigentlich wegen Speed und Ausfallsicherheit -
solltet Ihr mal mit dem Admin vor Ort (wo der Mysql Server steht) über MySQL Master Master Replication oder MySQL Master Slave Replication nachdenken.
Denn das ist dann auch eine Lösung, die diesen Namen verdient und kein Gefrickel
Gruß
Hallo,
Ja ok jetzt weis ich was du meinst. Danke für die Hilfe, werde es bei gelegenheit Ansprechen.
Grüße
Alex
Ja ok jetzt weis ich was du meinst. Danke für die Hilfe, werde es bei gelegenheit Ansprechen.
Grüße
Alex
