Office: lokale Tabelle befüllen

Ich brauch mal einen Denkanstoss:

ich habe eine (MySQL) Datenbank per ADODB im Zugriff.
Nun möchte ich mit den Daten eine lokale Tabelle befüllen.

Aber wie ich das sehe, habe ich "nur" die Möglichkeit ein Recordset- oder ein Command-Object damit zu öffnen, oder?

Und: ich würde es ungern in einer Schleife Satz für Satz erledigen ...
... sondern mit einem INSERT oder SELECT INTO Befehl ...

:)

 

Hallo!

ODBC-Zugriff ist nicht möglich?
Die Tabelle muss dafür nicht in der Access-DB verknüpft werden. Es reicht aus, wenn du einen ODBC-Treiber nutzen kannst.


mfg
Josef

 

Eine ADODB-Connection kann nur auf eine einzelne Datenbank errichtet werden.

In einem DAO-Workspace können dagegen mehrere Datenbanken miteinander verbunden werden. Man könnte also die eine Datenbank per Database-Variable referenzieren und für die andere die Verbindungsdaten direkt in den SQL-String schreiben.
Variante 1 etwa:
Code:

Siehe auch VBA-Hilfe zu Opendatabase.

Variante 2
Code:

Siehe Script Jet-SQL von Karl Donaubauer (AEK 5)

Für die Access-DB-Seite dann gleichwertig, aber einfacher.

In Unkenntnis: Könntest Du aus MySQL heraus einfach eine CSV erstellen?

 

\@Josef: Der ODBC Zugriff ist möglich, aber die Datenbank liegt im Internet und die fraglichen Tabellen sind recht groß so dass es (mit verknüpften Tabellen) zu irritierenden Latenzen kommt.

Aber wie greife ich drauf zu? Und wie kann ich die Daten dann kopieren?

Antwort: Variante 2 von Eberhard. Wer lesen kann ... *wink.gif*

@Eberhard: An die MySQL komme ich nur lesend und einen CSV Export kann ich aus der Ferne nicht anstossen. DonKarls Script aus der AEK werde ich mir mal anschauen, Danke für den Hinweis.

 

Also ein CSV kannst du mittels Recordset.getstring ganz leicht erstellen.

LG Markus

 

Muss ich mal ausprobieren. Danke schon mal für den Hinweis.

 

Ob das performancemäßig was bringt das CSV zu importieren/verknüpfen ist natürlich zu hinterfragen.

Viel interessanter wäre es zu wissen, warum du die Daten local brauchst.
Bleiben die gespeichert und werden die aktualisiert?
Geht es um Reports?
Oder gibt es andere Gründe?

Möglicherweise gibt es da einen anderen Ansatz.
LG Markus

 

Weil sie besichtigt,
ggf. geändert - aber eben nicht in der Original-DB -
und dann weiter verarbeitet werden

 

Ich hab jetzt übrigens bemerkt, dass das Einfügen externer Daten in die lokale Datenbank sowohl mittels dao.Database als auch mittels ado.Connection funktioniert.

Bei ado Connection gilt:

ConnectionLokaleDatenbank.Execute "Insert into tblDaten Select * From [Verbindung Externe Datenbank].tblDaten", , 129

Oder

ConnectionExterneDatenbank.Execute "Insert into [Verbindung Lokale Datenbank].tblDaten Select * From tblDaten", , 129

LG Markus

 

Das ist noch mal ein guter Tipp, Markus.
Vielen Dank.

 

Ich greife diesen Thread noch mal auf, da Eberhard mich darauf hinwies, weil hier einiges besprochen war, was in einem aktuelleren Thread zur Sprache kam.

Drei Tabellen sollen importiert werden.
O mit knapp 4.500, P mit etwa 2.600 und eine m:n Relation OP mit knapp 10.000 Sätzen.

Variante 2 aus #3 benötigt 11 Minuten. Indiskutabel.

Der Import aus Tabellen, die per ODBC verknüpft sind, dauert 4 Sekunden.
Das ist voll zufriedenstellend. Allerdings kommt es im weiteren Verfahren - wie oben beschrieben - immer wieder zu Latenzen und TimeOuts. Deshalb habe ich die Aktualisierung per ADO Connection realisiert.
Das klappt auch wunderbar.

Jetzt würde ich gerne den Import auch per ADO machen um ganz auf die verknüpften Tabellen verzichten zu können. Leider laufen beide Vorschläge von Markus aus #9 in Fehler (siehe anliegende Screenshots).
Code:

 

Dein Versuch ist Unsinn. Ein Connectionobjekt kann doch nicht Teil einer SQL-Anweisung sein, und eine Connection kannst Du auch nicht irgendwie mit einer anderen zusammenketten.

Ich würde so etwas erwarten:
Code:

Da hier die erste p-Tabelle die interne ist, wäre die Connection folglich auf deren Datenbank zu errichten.
Ggf. kommen zum Dateipfad noch einige Verbindungsdaten dazu.

 

Markus schrieb in #9, dass es funktioniert ...

Aus den Fehlermeldungen lese ich heraus, dass es einen Konflikt zwischen den Treiben für die MySQL und die ACCDB gibt, wenn sie gleichzeitig verwendet werden - vielleicht funktioniert es ja, wenn remote und local die gleichen Datenbank-Typen sind?

Aber hier ist es local die ACCDB und remote die MySQL.
Ich werde mal Eberhards Vorschlag aus #12 in diese Richtung anpassen.

 

In eine Jet-SQL-Anweisung kann man Verbindungsdaten hineinschreiben, nicht aber Verbindungsobjekte. Letztere kennt die DB-Maschine garantiert nicht.
In dem Zusammenhang würde ich nochmal auf das Donaubauer-Script verweisen: Jet-SQL

 

Hab das mal so probiert:
Code:

Kommt zumindest mal eine andere Fehlermeldung *wink.gif*

Ja, das habe ich mir heruntergeladen ... aber dort ist hinsichtlich externer Daten nur die schnarchlangsame Version zu finden, die Du in #3 vorschlugst.