<\/p>\n
Haben Sie Ihr Backend in ein DBMS ausgelagert, also die Tabellen auf einen SQL-Server migriert, so steht Ihnen ab Access 2007 nur noch die Schnittstelle ADODB zur Verfügung, um unter VBA auf sie zuzugreifen, falls Sie sich nicht nur auf verknüpfte Tabellen beschränken möchten. Denn die Technologie ODBCDirect, mit der man direkt eine Verbindung zum Server aufbauen konnte, wurde ersatzlos gestrichen. Mit einem Trick schlagen Sie Microsoft jedoch ein Schnippchen!<\/b><\/p>\nODBCDirect<\/h2>\n
Es handelt sich dabei eine Datenschnittstelle, die in der Bibliothek DAO<\/b> untergebracht ist. Dort finden Sie ein Connection<\/b>-Objekt, welches allein für die Kommunikation mit einem SQL-Server über ODBC<\/b> zuständig ist (s. Bild 1). Doch offenbar enthält die Bibliothek diese Klasse nur noch aus Kompatibilitätsgründen, denn jeglicher Methodenaufruf auf sie endet mit einer Fehlermeldung 3827: ODBCDirect wird nicht mehr unterstützt. Schreiben Sie den Code so um, dass ADO anstelle von DAO verwendet wird<\/b>. Das können Sie tun, denn etwas anderes bleibt Ihnen nun auch nicht übrig. <\/p>\n
![\"Die](\"..\/fileadmin\/_temp_\/2018_05\/Connection_Objektkatalog.png\")
<\/p>\n
Bild 1: Die ODBCDirect-Klasse Connection im Objektkatalog von VBA<\/span><\/b><\/p>\n Der Sachverhalt stellt sich in der Praxis nicht selten ein. Haben Sie etwa eine ältere Access 2003<\/b>-Datenbank im Einsatz, die ODBCDirect<\/b> nutzt, und auf den Rechnern soll Office 2010<\/b> installiert werden, so kommen Sie um Anpassungen leider nicht herum. Statt der DAO-Connection<\/b> verwenden Sie nun überall eine ADODB-Connection<\/b>, deren Methoden aber deutlich abweichen! Hier ist einiges an Arbeit für die Migration angesagt. <\/p>\n Warum Microsoft die Schnittstelle entfernte, ist nicht nachzuvollziehen. Einerseits wurden die sogenannten Access-Projekte<\/b> (ADP<\/b>) in welchen Sie Formulare unmittelbar an einen MSSQL<\/b>-Server binden konnten, ab Access 2007<\/b> komplett entfernt und stattdessen wurden ODBC-verknüpfte Tabellen empfohlen. Gleichzeitig aber strich man ODBCDirect<\/b>. Ich habe dafür nur eine Erklärung: Einst waren SQL-Server ziemlich teuer, weshalb sie häufig für Low Budget-Lösungen mit Access nicht infrage kamen. Zudem scheuten viele Entwickler den Einsatz des SQL-Servers, weil hier eine Menge zusätzliches Knowhow zu erwerben war. In der Folge fanden Sie in den einschlägigen Foren und Newsgroups nur selten Fragen zum Thema ODBCDirect<\/b>. Für Microsoft offenbar Grund genug, sich dieser Schnittstelle zu entledigen.<\/p>\n Inzwischen aber stellt nicht nur Microsoft selbst einen kostenlosen leistungsfähigen Server (SQL Server Express<\/b>) zur Verfügung, sondern auch andere Größen der Branche, wie IBM<\/b> mit DB2 Express<\/b> oder Oracle<\/b> mit Express 11g<\/b>, von den OpenSource<\/b>-Lösungen MySQL<\/b>, MariaDB<\/b>, Postgres<\/b> und Firebird<\/b> ganz zu schweigen, sodass der Einsatz dieser DBMS<\/b> als Backend, die der Access Engine<\/b> klar den Rang ablaufen, naheliegt.<\/p>\n Wollen Sie hier ADODB<\/b> verwenden, so hat dies einen Haken: Viele der genannten DBMS<\/b> stellen keinen OLEDB-Provider<\/b> zur Verfügung. Manche sind instabil oder wenig performant, bei manchen finden Sie gar keinen. Dann müssen Sie den ODBC-Provider MSDASQL<\/b> nehmen, der aber eine zusätzliche Ebene einzieht und deshalb in der Performance das Nachsehen hat.<\/p>\n Empfehlung: Voten Sie auf access.uservoice<\/b> für die Wiederaufnahme von ODBCDirect<\/b>! Dort nimmt Microsoft Vorschläge zu zukünftigen Access-Versionen entgegen. Früher einmal gab es das Connect<\/b>-Programm von Microsoft, wo vornehmlich MVPs<\/b> ihre Vorschläge einbrachten. Die wurden allerdings nicht wirklich ernst genommen. Offenbar hat sich dies geändert. Nach dem Debakel mit den Access-WebServices<\/b>, die in der Zukunft deshalb eben entfallen sollen, wendet man sich nun anscheinend vermehrt den Anregungen der Community zu, wie etwa die Wiedergeburt der dBase<\/b>-Schnittstelle zeigt.<\/p>\n Die Programmierung der ODBCDirect<\/b>-Schnittstelle ist fast so einfach, wie die von lokalen oder verlinkten Access-Tabellen:<\/p>\n Hier wird zunächst ein Workspace oWrk<\/b> angelegt, welches von dem abweicht, das die DBEngine<\/b> von Access.Application<\/b> voreingestellt hat, weil die Konstante dbUseODBC<\/b> angegeben ist. Der Normalfall wäre dbUseJet<\/b>. Dann wird in sConx<\/b> der Connect<\/b>-String zusammengebaut, der mit dem Tag ODBC;<\/b> beginnen muss.<\/p>\n Mit Driver<\/b> geben Sie den Namen eines installierten ODBC-Treibers an, in unserem Fall den dBase<\/b>-Treiber. Daran schließen sich treiberspezifische Optionen an. Hier ist es vor allem der Pfad, unter dem sich die dBase<\/b>-Dateien befinden, im Schlüssel Dbq<\/b>.<\/p>\n Mit diesem Connect<\/b>-String öffnen Sie das Connection<\/b>-Objekt oConx<\/b>. ähnlich, wie bei einem Database<\/b>-Objekt, können Sie nun ein Recordset<\/b> über ein SQL-Statement auf die Connection<\/b> öffnen.<\/p>\n Korrekt. Führen Sie den angeführten Code in einer ACCDB<\/b> aus, so tritt die erwähnte Fehlermeldung auf.<\/p>\n Sie könnten nun auf die Idee kommen, statt der ACE<\/b>-Bibliothek die alte zu verwenden. Löschen Sie also den Verweis auf DAO<\/b> und laden Sie einen auf DAO.36<\/b> neu (Microsoft DAO 3.6 Object Library<\/b>). Tatsächlich ändert dies am Sachverhalt rein gar nichts. Denn der Verweis führt nicht dazu, dass die alte Engine geladen würde.<\/p>\n Da die alte, wie die neue, den Namen DAO<\/b> trägt, verwendet Access weiterhin die interne ADEDAO.dll<\/b>, die bereits beim Start von Access geladen wird. Die Bibliothek selbst wird zwar von VBA genutzt, doch quasi nur als Tabelle für die Klassen, die unter beiden Bibliotheken an dieselben GUIDs<\/b> und Methoden für die Interfaces<\/b> gebunden sind.<\/p>\n Der nächste Versuch wäre, eine eigene DBEngine<\/b> anzulegen, die auf die dao360.dll<\/b> verweist. Das lässt sich über die Methode CreateObject<\/b> erledigen:<\/p>\n Verblüffend, auch dies zeitigt dieselbe Fehlermeldung in der letzten Zeile! Hier ist der Grund der, dass die Office-Installation in der Registry die ProgID- und CLSID-Schlüssel so verbogen hat, dass sie ebenfalls auf die acedao.dll verweisen. Also scheinen wohl alle Wege verbaut zu sein.<\/p>\n In der letzten Ausgabe erfuhren Sie, wie Sie COM-Objekte<\/b> instanziieren können, ohne dass jene im System registriert sein müssen (ActiveX und COM ohne Registrierung verwenden<\/b>). Dabei kommt ein Modul zum Einsatz (mdlComLoaderASM<\/b>), das ziemlich komplex ist und auch vor Assembler<\/b>-Teilen nicht Halt macht. Hier haben Sie nun eine nützliche Anwendung für die Routinen des Moduls: Wir versuchen, eine Instanz der alten JET-Engine<\/b> über die Funktion GetCOMInstance<\/b> zu erhalten. Das geht im Prinzip so:<\/p>\n Und, siehe da, die Sache klappt, und wir haben Microsoft ausgetrickst! Natürlich muss in der Variablen sFile<\/b> zuvor der Pfad zur dao360.dll stehen.<\/p>\n Aber gibt es diese Datei überhaupt auf dem Rechner mit Office 2007<\/b> ff. Wir können das nicht für alle Fälle versichern. Doch die dao360.dll<\/b> wird auch von Windows selbst für seine Zwecke genutzt, weshalb die Datei nach unseren Beobachtungen mit diesem installiert wird. Auch der Pfad scheint immer derselbe zu sein. Sie können ihn vom Pfad der ACEDAO<\/b> ableiten, wenn auf diese ein Verweis gesetzt ist:<\/p>\n Heraus kommt dabei der String<\/p>\n Möchten Sie also Ihre alte Access 2003<\/b>-Datenbank, die ODBCDirect<\/b> nutzt, nach Access 2010<\/b> migrieren, so ersetzen Sie im Code einfach alle Aufrufe auf das Connection<\/b>-Objekt etwa mit dieser Routine:<\/p>\n Das Connection<\/b>-Objekt steht damit generell im VBA-Projekt zur Verfügung. Auf Umgestaltung nach ADO<\/b> können Sie getrost verzichten. <\/p>\n Ein Anwendungsbeispiel finden Sie in Listing 1. Wie zuvor ausgeführt erzeugt GetCOMInstance<\/b> hier eine neue DBEngine<\/b>. Statt der ProgID<\/b> DBEngine<\/b> allerdings ist die entsprechende CLSID<\/b> für das Objekt der Begierde eingesetzt. GetCOMInstance<\/b> muss nämlich sonst die CLSID<\/b> aus der ProgID<\/b> selbst ermitteln, was Sie der Prozedur abnehmen können.<\/p>\n <\/p>\n Listing 1: Diese Prozedur erzeugt eine Instanz der DBEngine und spricht damit einen MySQL-Server an.<\/span><\/b><\/p>\n Den Connect<\/b>-String sConx<\/b> verweist in diesem Beispiel auf einen MySQL-ODBC<\/b>-Treiber. Der Server wird über den Standard-Port 3306<\/b> auf die lokale Maschine mit der IP<\/b> 127.0.0.1<\/b> angesprochen und der Benutzername zur Autorisierung am Server ist root<\/b>, das Passwort ist aiupwd<\/b>. Die Connection<\/b> oConx<\/b> wird über diesen String geöffnet.<\/p>\n Interessant ist in diesem Zusammenhang die Konstante dbDriverNoPrompt<\/b>. Sie sagt ODBCDirect<\/b>, dass kein Dialog erscheinen soll, wenn etwas am Connect<\/b>-String nicht stimmt. In diesem Fall käme es zu einer Fehlermeldung. <\/p>\n Setzten Sie stattdessen dbDriverCompleteRequired<\/b> ein, so erscheint der ODBC<\/b>-Dialog des Datenquellenadministrators<\/b> von Windows. In dem sind dann die korrekten Angaben zur Verbindung vorausgefüllt. Lassen Sie etwa den Benutzernamen weg, so können Sie diesen dann im Dialog nachreichen.<\/p>\n Schließlich öffnet sich ein Recordset rs<\/b> auf die Tabelle tblArtikel<\/b> auf die Connection<\/b>. In der folgenden Schleife werden dann die Werte der Felder ID<\/b> und Artikel<\/b> der Datensätze alle im VBA-Direktfenster ausgegeben. Zu erwähnen wäre, dass diese Methode erheblich performanter ist, als ADO<\/b> über ODBC<\/b> auf den MySQL-Treiber. Es gibt nämlich keinen funktionierenden kostenlosen MySQL<\/b>– oder MariaDB-OLEDB-Provider<\/b>.<\/p>\n Noch ein Feature ist ab Access 2013<\/b> dem Rotstift anheimgefallen: die Schnittstelle zu dBase<\/b>. Bis dahin konnte man noch über das Ribbon<\/b> und Externe Daten<\/b> dBase<\/b>-Dateien sowohl importieren, wie verknüpfen oder exportieren. Das geht unter Umständen eben nicht mehr, obwohl die Schnittstelle im neuesten Access 2016 <\/b>wieder drin ist. dBase<\/b> ist als Austauschformat und Schnittstelle zu manchen anderen Programmen (leider) noch immer aktuell.<\/p>\n Der Umweg über eine DSN<\/b>, welche Sie auf dBase<\/b>-Dateien im ODBC-Datenquellen-Administrator<\/b> anlegen, klappt ebenfalls nicht. Der Versuch, darauf eine ODBC<\/b>-Verknüpfung in Access aufzubauen scheitert mit der Meldung Verknüpfen von externen ISAM-Datenbanktabellen mit Ihrer Datenbank über ODBC ist nicht möglich <\/b>– warum auch immer das so unsinnigerweise vorgesehen wurde. Die einzige Lösung ist hier in VBA ODBCDirect<\/b> im Verein mit GetCOMInstance<\/b>. Auch eine Passthrough-Abfrage<\/b> auf den ODBC<\/b>-Treiber funktioniert nicht, wie die Abfrage qry_PT_dBase<\/b> der Demodatenbank zeigt.<\/p>\n Kleiner Tipp am Rande: Unter Windows 64<\/b> existiert wohl schon im Startmenü ein Link zum ODBC-Datenquellenadministrator<\/b>. Doch dieser öffnet die 64bit-Version desselben, in der demnach auch nur 64bit-Treiber aufgelistet sind. Mit diesen kann Office x32<\/b> nichts anfangen. Legen Sie sich deshalb eine Verknüpfung zur Version unter SysWOW64<\/b> auf dem Desktop an (C:\\Windows\\SysWOW64\\odbcad32.exe<\/b>). Sie sollte nach dem Start den Dialog ähnlich zeigen, wie in Bild 2.<\/p>\n Bild 2: Der 32bit-ODBC-Datenquellen-Administrator listet die 32bit-Treiber auf.<\/span><\/b><\/p>\n Sie können nun eine neue Benutzer-DSN<\/b> zu dBase<\/b>-Dateien anlegen, indem Sie unter dem entsprechenden Reiter die Schaltfläche Neu anklicken. In Bild 3 ist der Dialog nach Auswahl des dBase<\/b>-Treibers ausgefüllt. übrigens können wir auch nicht garantieren, dass der Treiber auch wirklich auf Ihrem System installiert ist. Im Zweifel können Sie das nachholen, indem Sie das Microsoft ODBC Desktop Driver Pack<\/b> installieren. Infos zum dBase<\/b>-Treiber gibt es dann etwa in den Microsoft Docs<\/b>.<\/p>\n Bild 3: So sieht die Anlage einer DSN im ODBC-Dialog zu dBase-Dateien aus.<\/span><\/b><\/p>\n Für unsere ODBCDirect<\/b>-Verbindung benötigen wir eine solche DSN<\/b> nicht, weil wir die DSNless<\/b> anlegen. Der Dialog macht jedoch deutlich, was es mit dem dBase<\/b>–DBMS<\/b> auf sich hat. Sie wählen am besten die Treiberversion 5.0<\/b> aus, die im Connect<\/b>-String dem Eintrag DriverID=533<\/b> entspricht. Ansonsten geben Sie lediglich ein Verzeichnis an, in dem sich die dBase<\/b>-Dateien befinden, was sich im Parameter Dbq<\/b> wiederspiegelt. Die Verbindung geschieht also nicht zu einer einzelnen Datei, sondern zu einem Verzeichnis, das quasi die Datenbank darstellt, während die Dateien die einzelnen Tabellen sind.<\/p>\n Listing 2 zeigt den kompletten Code, der an sich nur eine erweiterte Version der MySQL<\/b>-Routine darstellt. Interessant ist hier die SQL-Syntax beim öffnen des Recordset. Da eine dBase<\/b>-Datei imgrunde eine Tabelle darstellt, müssen Sie die auch im FROM<\/b>-Statement samt Dateierweiterung angeben (KUNDENLI.dbf<\/b>). <\/p>\n Listing 2: Die Prozedur öffnet eine dBase-Tabelle und gibt sämtliche Datensätze im Direktfenster aus.<\/span><\/b><\/p>\n Die Routine schreibt über die erste Spalte alle Feldnamen der Tabelle in das Direktfenster. In der zweiten verschachtelten Schleife geschieht dies jeweils für jeden Datensatz, wobei dann nicht Field.Name<\/b> ausgegeben wird, sondern Field.Value<\/b>. Die dBase<\/b>-Datei ist durch Export aus einer Access-Tabelle Kundenliste<\/b> entstanden. Sie sehen, dass dBase<\/b> den Namen abkürzt.<\/p>\n Unter dBase III <\/b>können Tabellennamen nur acht Zeichen lang sein. Feldnamen können länger sein. Weitere Spezifikationen finden Sie etwa unter folgendem Link:<\/p>\n Zwar können Sie nun unter VBA über ODBCDirect<\/b> auf die Daten eines SQL-Servers zugreifen. Vielleicht aber möchten Sie diese auch in einem Formular anzeigen, anstatt sie lediglich per Code weiterzuverarbeiten.<\/p>\n über die Eigenschaft Recordset<\/b> eines Formulars, die nicht nur Lese-, sondern auch Schreibzugriff gestattet, könnten Sie ein ODBCDirect<\/b>-Recordset direkt zuweisen. Das allerdings funktioniert nicht. Sie erhalten bei Zuweisung die Fehlermeldung Das Objekt ist kein gültiges Recordset.<\/b> Denn Formulare unterstützen nur die normalen DAO<\/b>-Recordsets oder ADO<\/b>-Recordsets.<\/p>\n Entweder verzichten Sie nun auf Formularfelder und geben die Feldwerte des Recordsets in einem Listenfeld aus, oder Sie wandeln das ODBC<\/b>–Recordset<\/b> in ein anderes vom Formular unterstütztes um. DAO<\/b> scheidet hier eigentlich aus, weil Sie da ein Recordset<\/b> nur auf eine physische Tabelle öffnen können. Anders bei ADO<\/b>, wo ein Disconnected Recordset<\/b> auch künstlich erzeugt werden kann. Zu dieser Methode haben wir gegriffen, wobei die Lösung nur eine rudimentäre ist, da auf Datentypkonvertierung verzichtet wurde. Der Kern der Lösung besteht in der Klasse cODBCConnection<\/b>, welche ODBCDirect<\/b> komplett kapselt.<\/p>\n cODBCConnection<\/b> hat folgende Methoden und Eigenschaften:<\/p>\n Die letzte Methode ist auch die einzige, die wir näher beleuchten wollen, da die anderen Routinen weitgehend nur das bisher schon Gesagte wiederspiegeln. Listing 3 stellt die Prozedur dar.<\/p>\n Listing 3: Die Funktion konvertiert ein ODBC-in ein ADO-Recordset.<\/span><\/b><\/p>\n Die Objektvariable rs<\/b> speichert zunächst das ODBC-Recordset, welches über die andere Klassenfunktion OpenRecordset<\/b> und den übergebenen SQL-String erhalten wird. Anschließend wird ein mit New<\/b> deklariertes ADODB-Recordset<\/b> von Grund auf neu erstellt. Dazu klappert die erste Schleife über die Fields<\/b>-Auflistung alle Felder des ODBC-Recordsets<\/b> ab und fügt dem ADO-Recordset rsADO<\/b> gleichnamige hinzu, wobei als Datentyp adBSTR<\/b> verwendet wird. Das ist der String-Typ für normalen Text. adVarChar<\/b> scheidet aus, weil Access hier nicht mit Unicode-Zeichen klarkäme. Nach dem öffnen des ADO-Recordsets per Open<\/b>-Anweisung können diesem direkt per AddNew<\/b> neue Datensätze angefügt werden, was die zweite Schleife erledigt. Ein Update nach jedem Durchgang ist bei ADO<\/b> nicht nötig: Das abschließende UpdateBatch<\/b> speichert alles auf einen Schlag, wie bei einer Transaktion. Das ODBC-Recordset rs <\/b>kann nun geschlossen werden. Das Recordset rsADO<\/b> wird nun als Rückgabewert der Funktion gesetzt.<\/p>\n So kurz die Routine auch ist, die Performance ist durch diese Konvertierung natürlich nicht überwältigend. Zur Anzeige in einem Formular spielt dies jedoch eine untergeordnete Rolle. Klar ist zudem, dass die Daten dieses Recordsets zwar auch beschrieben oder neue hinzugefügt werden können, dies sich jedoch nicht rückwärts auf die dBase<\/b>-Datei auswirkt.<\/p>\n Diese Klasse cODBCConnection<\/b> wird nun vom Formular frmKundenliste<\/b> der Demo benutzt, um seine Textfelder zu füllen. Der Entwurf des Formulars in Bild 4 zeigt zehn Textfelder und zehn an sie geknüpfte Labels. Die Ansicht ist auf Datenblatt<\/b> eingestellt, weshalb der Inhalt der Labels später die Spaltenköpfe angibt. Die Labels haben Namen von L1<\/b> bis L10<\/b>, die ungebundenen Textfelder nennen sich T1<\/b> bis T10<\/b>. Die Aufgabe des Startcodes des Formulars ist es nun, die Labels mit den Feldnamen des ADO-Recordsets zu füllen (Caption<\/b>) und zweitens den Steuerelementinhalt der Textfelder (ControlSource<\/b>) ebenfalls auf diese Namen, damit eine Verknüpfung hergestellt wird. Natürlich hätte man diese Elemente auch alle voreinstellen können, wenn bekannt wäre, wie die dBase<\/b>-Daten aufgebaut sind. Das Formular soll jedoch beliebige dBase<\/b>-Dateien anzeigen können, weshalb dieser allgemeine Aufbau gewählt wurde. <\/p>\n Bild 4: Im Entwurf zeigt das Formular nur zehn Textfelder und Labels.<\/span><\/b><\/p>\n Da die Anzahl der Felder des ADO-Recordsets nicht bekannt ist, müssen die nicht genutzten Spalten zur Laufzeit ausgeblendet werden. Sonst zeigen sich die Textfelder im Datenblatt rechts neben den gültigen Spalten, wie ID<\/b>, Kundencode<\/b>, Firma<\/b>, etwa als T8<\/b>, T9<\/b>, T10<\/b> mit leeren Zellen. Dazu wird die Eigenschaft ColumnHidden<\/b> der entsprechenden Textfelder per Code auf True<\/b> gesetzt. Würden Sie ein Formular in Formularansicht<\/b> verwenden, so müssten Sie lediglich die Visible<\/b>-Eigenschaft der Textfelder und Labels steuern.<\/p>\n Wenn Sie wissen, dass Ihre dBase<\/b>-Dateien auch Tabellen mit mehr als zehn Feldern aufweisen, so können Sie das Formular ja erweitern und mehr Textfelder und Labels einbauen. Ich exportiere etwa meine Bankumsätze aus StarMoney<\/b> in das dBase<\/b>-Format, um sie unter Access für Steuererklärungen analysieren zu können. Die resultierende Datei weist 33 Felder auf. Damit kann das Demoformular in vorliegender Version nicht umgehen.<\/p>\n Zu erwähnen wäre noch, dass die Eigenschaften Daten eingeben<\/b>, Anfügen zulassen<\/b>, Löschen zulassen<\/b> und Bearbeitungen zulassen<\/b> des Formulars alle auf Nein<\/b> eingestellt sind. Denn all dies wäre beim ADO-Recordset durchaus möglich, ergibt jedoch wenig Sinn, wenn sich solche änderungen an den Daten nicht auch in der dBase<\/b>-Datei reflektieren. Lediglich Filter zulassen<\/b> steht auf Wahr<\/b>.<\/p>\n Starten Sie einmal das Formular. Es stellt sich die Ansicht wie in Bild 5 ein, die sich aus dem Laden der Datei kundenli.dbf<\/b> ergibt. Nach fünf Sekunden jedoch kommt es zur Ansicht in Bild 6, was die Datei orte.dbf<\/b> repräsentiert. Das Spiel wiederholt sich alle fünf Sekunden. Das haben wir spaßeshalber nur zur Demonstration dessen eingebaut, dass das Formular dynamisch mit unterschiedlichen Datenquellen umgehen kann.<\/p>\n Bild 5: Zur Laufzeit zeigen sich die Daten der dBase-Datei korrekt im auf dem ADO-Recordset basierenden Formular frmKundenliste.<\/span><\/b><\/p>\n Bild 6: Der Timer des Formulars wechselt die Datenherkunft alle 5 Sekunden und führt damit alternativ zur Anzeige der Datei aus orte.dbf.<\/span><\/b><\/p>\n Listing 4 zeigt den wesentlichen Teil des Formularmoduls. Beim öffnen wird eine neue Instanz der Klasse cODBCConnection<\/b> in der Variablen C<\/b> erzeugt. ConnectSilent<\/b> weist an, beim Verbinden auf keinen Fall den ODBC-Dialog aufzurufen. Weiter geht es mit Form_Load<\/b>. Dort wird lediglich der Zeitgeber des Formulars auf 5.000 ms<\/b> eingestellt, die Timer<\/b>-Routine Form_Timer<\/b> aber auch gleich künstlich aufgerufen. Denn nur die führt zur Anzeige der dBase<\/b>-Daten. Sie verneint die modulweit gültige Boolean-Variable b<\/b>, so dass diese bei jedem Zeitgeberaufruf von True<\/b> auf False<\/b> und umgekehrt wechselt. Erst die nun aufgerufene zentrale Prozedur ChangeDB<\/b> wertet die Variable aus.<\/p>\nDim <\/span>oWrk As <\/span>DAO.Workspace\r\nDim <\/span>oConx As <\/span>DAO.Connection\r\nDim <\/span>sConx As String<\/span>\r\nDim <\/span>rs As <\/span>DAO.Recordset\r\nSet<\/span> oWrk = oDbEng.CreateWorkspace(\"\", \"\", \"\", dbUseODBC)\r\nsConx = \"ODBC;Driver={Microsoft dBase Driver (*.dbf)}\" & _\r\n \";DriverID=533\";Dbq=\" & CurrentProject.Path\r\nSet<\/span> oConx = oWrk.OpenConnection(\"\", , , sConx)\r\nSet<\/span> rs = oConx.OpenRecordset( _\r\n \"SELECT * FROM KUNDENLI.DBF.DBF\", dbOpenDynaset)<\/pre>\nAber das geht doch gar nicht mehr!<\/h2>\n
Dim <\/span>oDBEng As Object<\/span>\r\nDim <\/span>oWrk As Object<\/span>\r\nSet<\/span> oDbEng = CreateObject(\"DAO.DBEngine.36\")\r\nSet<\/span> oWrk = oDbEng.CreateWorkspace(\"\", \"\", \"\", dbUseODBC)<\/pre>\nEs geht doch!<\/h2>\n
Dim <\/span>oDbEng As <\/span>DAO.DBEngine\r\nDim <\/span>oWrk As <\/span>DAO.Workspace\r\nSet<\/span> oDbEng = GetCOMInstance(sFile, \"DBEngine\", True<\/span>)\r\nSet<\/span> oWrk = oDbEng.CreateWorkspace(\"\", \"\", \"\", dbUseODBC)<\/pre>\nsFile = References(\"DAO\").FullPath\r\nsFile = Replace<\/span>(sFile, \"OFFICE14\\ACEDAO.DLL\", _\r\n \"DAO\\dao360.dll\")<\/pre>\nC:\\Program Files (x86)\\Common Files\\Microsoft Shared\\DAO\\dao360.dll<\/pre>\n
Dim <\/span>oConx As <\/span>DAO.Connection\r\nDim <\/span>oDbEng As <\/span>DAO.DBEngine\r\nDim <\/span>oWrk As <\/span>DAO.Workspace\r\nFunction <\/span>Connection As <\/span>DAO.Connection\r\nDim <\/span>sFile As String<\/span>\r\nIf <\/span>oConx Is Nothing Then<\/span>\r\n sFile = References(\"DAO\").FullPath\r\n sFile = Replace<\/span>(sFile, \"OFFICE14\\ACEDAO.DLL\", _\r\n \"DAO\\dao360.dll\")\r\n Set<\/span> oDbEng = GetCOMInstance(sFile, \"DBEngine\", True<\/span>)\r\n Set<\/span> oWrk = oDbEng.CreateWorkspace(\"\", \"\", \"\", dbUseODBC)\r\nEnd If<\/span>\r\nSet<\/span> Connection = oConx\r\nEnd Function<\/span><\/pre>\nSub <\/span>ConnectMysqlODBCDirect()\r\n Dim <\/span>oDbEng As <\/span>DAO.DBEngine\r\n Dim <\/span>oWrk As <\/span>DAO.Workspace\r\n Dim <\/span>oConx As <\/span>DAO.Connection\r\n Dim <\/span>sConx As String<\/span>\r\n Dim <\/span>rs As <\/span>DAO.Recordset\r\n Dim <\/span>sFile As String<\/span>\r\n \r\n sFile = Replace<\/span>(References(\"DAO\").FullPath, \"OFFICE14\\ACEDAO.DLL\", \"DAO\\dao360.dll\")\r\n \r\n Set<\/span> oDbEng = GetCOMInstance(sFile, _\r\n \"{00000100-0000-0010-8000-00AA006D2EA4}\", True<\/span>)\r\n ''''oder statt CLSID: DBEngine ~ DAO.DBEngine.36\r\n \r\n Set<\/span> oWrk = oDbEng.CreateWorkspace(\"\", \"\", \"\", dbUseODBC)\r\n sConx = \"ODBC;Driver={MySQL ODBC 5.3 ANSI Driver};\" & _\r\n \"DATABASE=mysqlbackend;\" & _\r\n \"SERVER=127.0.0.1;PORT=3306;\" & _\r\n \"UID=root;PWD=aiupwd;OPTION=18475\"\r\n Set<\/span> oConx = oWrk.OpenConnection(\"\", dbDriverNoPrompt, , sConx)\r\n ''''oder dbDriverCompleteRequired\r\n Set<\/span> rs = oConx.OpenRecordset( _\r\n \"SELECT ID,Artikel FROM tblArtikel\", dbOpenDynaset)\r\n Do While<\/span> Not<\/span> rs.EOF\r\n Debug.Print<\/span> rs(0).Value, rs(1).Value\r\n rs.MoveNext<\/span>\r\n Loop<\/span>\r\n rs.Close\r\n \r\n On Error Resume Next<\/span>\r\n oWrk.Close\r\n Set<\/span> oWrk = Nothing\r\n oConx.Close\r\n Set<\/span> oConx = Nothing\r\n Set<\/span> oDbEng = Nothing\r\nEnd Function<\/span><\/pre>\ndBase über ODBCDirect<\/h2>\n
![\"Der](\"..\/fileadmin\/_temp_\/2018_05\/ODBCAdm32.png\")
<\/p>\n![\"So](\"..\/fileadmin\/_temp_\/2018_05\/ODBC_dBase_DSN.png\")
<\/p>\nSub <\/span>ConnectdBaseODBCDirect()\r\n Dim <\/span>sFile As String<\/span>, sPath As String<\/span>\r\n Dim <\/span>oDbEng As <\/span>DAO.DBEngine\r\n Dim <\/span>oWrk As <\/span>DAO.Workspace\r\n Dim <\/span>oConx As <\/span>DAO.Connection, sConx As String<\/span>\r\n Dim <\/span>rs As <\/span>DAO.Recordset, fld As <\/span>DAO.Field\r\n \r\n sPath = CurrentProject.Path\r\n sFile = References(\"DAO\").FullPath\r\n sFile = Replace<\/span>(sFile, \"OFFICE14\\ACEDAO.DLL\", \"DAO\\dao360.dll\")\r\n Debug.Print<\/span> sFile\r\n \r\n Set<\/span> oDbEng = GetCOMInstance(sFile, _\r\n \"{00000100-0000-0010-8000-00AA006D2EA4}\", True<\/span>)\r\n Set<\/span> oWrk = oDbEng.CreateWorkspace(\"\", \"\", \"\", dbUseODBC)\r\n sConx = \"ODBC;Driver={Microsoft dBase Driver (*.dbf)};DriverID=533;Dbq=\" & sPath\r\n Set<\/span> oConx = oWrk.OpenConnection(\"\", dbDriverCompleteRequired, , sConx)\r\n Set<\/span> rs = oConx.OpenRecordset(\"SELECT * FROM KUNDENLI.DBF\", dbOpenDynaset)\r\n For Each fld In rs.Fields\r\n Debug.Print<\/span> fld.Name,\r\n Next<\/span> fld\r\n Debug.Print<\/span>\r\n Do While<\/span> Not<\/span> rs.EOF\r\n For Each fld In rs.Fields\r\n Debug.Print<\/span> fld.Value,\r\n Next<\/span> fld\r\n Debug.Print<\/span>\r\n rs.MoveNext<\/span>\r\n Loop<\/span>\r\n rs.Close\r\n \r\n On Error Resume Next<\/span>\r\n oWrk.Close: Set<\/span> oWrk = Nothing\r\n oConx.Close: Set<\/span> oConx = Nothing\r\n Set<\/span> oDbEng = Nothing\r\nEnd Function<\/span><\/pre>\nhttp:\/\/www.manmrk.net\/tutorials\/database\/xbase\/dbase_spec.html<\/pre>\n
ODBCDirect-Daten im Formular<\/h2>\n
\n
Function <\/span>OpenRecordsetADO(ByVal sSQL As String<\/span>) _\r\n As <\/span>ADODB.Recordset\r\n Dim <\/span>rs As <\/span>DAO.Recordset,.\r\n Dim <\/span>fld As <\/span>DAO.Field\r\n Dim <\/span>rsADO As <\/span>New<\/span> ADODB.Recordset\r\n \r\n Set<\/span> rs = OpenRecordset(sSQL)\r\n rsADO.CursorLocation = adUseClient\r\n For Each fld In rs.Fields\r\n rsADO.Fields.Append fld.Name, adBSTR\r\n Next<\/span> fld\r\n rsADO.Open\r\n rs.MoveFirst\r\n Do While<\/span> Not<\/span> rs.EOF\r\n rsADO.AddNew<\/span>\r\n For Each fld In rs.Fields\r\n rsADO(fld.Name).Value = Nz(fld.Value)\r\n Next<\/span> fld\r\n rs.MoveNext<\/span>\r\n Loop<\/span>\r\n rsADO.UpdateBatch adAffectAll\r\n rs.Close\r\n Set<\/span> OpenRecordsetADO = rsADO\r\nEnd Function<\/span><\/pre>\n![\"Im](\"..\/fileadmin\/_temp_\/2018_05\/frmKundenliste_DS.png\")
<\/p>\n![\"Zur](\"..\/fileadmin\/_temp_\/2018_05\/frmKundenliste_RT.png\")
<\/p>\n![\"Der](\"..\/fileadmin\/_temp_\/2018_05\/frmKundenliste_RT2.png\")
<\/p>\nDim <\/span>rs As <\/span>ADODB.Recordset\r\nDim <\/span>C As <\/span>cODBCConnection\r\nDim <\/span>b As Boolean<\/span>\r\nPrivate Sub <\/span>Form_Open(Cancel As Integer<\/span>)\r\n Set<\/span> C = New<\/span> cODBCConnection\r\n C.ConnectSilent = False<\/span>\r\nEnd Sub<\/span>\r\nPrivate Sub <\/span>Form_Load()\r\n DoCmd.Maximize\r\n Me.TimerInterval = 5000: Form_Timer\r\nEnd Sub<\/span>\r\nPrivate Sub <\/span>Form_Timer()\r\n b = Not<\/span> b\r\n ChangeDB\r\nEnd Sub<\/span>\r\nPrivate Sub <\/span>ChangeDB()\r\n Dim <\/span>i