Warum ODBC

Es gibt im wesentlichen zwei Gründe warum mit anderen Datenbanken als dBase-Tabellen gearbeitet wird. Zum einen gibt es häufig die Notwendigkeit auf bestehende "nicht dBase" Datenbestände zuzugreifen, zum anderen ist dies bei größeren Benutzerumgebungen sinnvoll. Für kleinere Anwendungen mit wenigen Benutzern reicht es normalerweise aus, mit dbase-Tabellen zu arbeiten. Spätestens bei einer gleichzeitigen Nutzeranzahl von 5 und mehr Benutzern sollte man sich bei der Erstellung der Anwendung darüber Gedanken machen, ob nicht eine andere Datenbank-Variante besser wäre. Beim Zugriff über langsamere Netzwerkverbindungen bleibt sowieso nur ein SQL-Server übrig, oder aber ein Terminalserver-Zugriff. SQL-Server bieten schnellere Zugriffe besonders bei Auswertungen und erzeugen einen niedrigeren Netzverkehr, da die Berechnungen auf dem Server stattfinden und immer nur die Ergebnisse vom Server übertragen werden. Dies ist mit dbase-Tabellen nicht möglich. Hier werden im Hintergrund immer die kompletten Datenbestände übertragen und auf dem Client ausgewertet. Außerdem bieten SQL-Server eine höhere Sicherheit, denn die Benutzer müssen keine Lese- und Schreibrechte im Verzeichnis haben in dem die Datenbank liegt. Bei dBase müssen immer alle Benutzer Lese- und Schreibrechte auf das Tabellenverzeichnis haben und könnten dort auch beliebig Tabellen löschen etc. Es gibt noch eine ganze Reihe weiterer guter Gründe für den Einsatz von SQL-Servern, auf die ich hier aber aus Platzgründen nicht eingehen will.

Unabhängig vom Grund der Notwendigkeit ist die Art des Zugriffs auf andere Datenquellen gleich. Die BDE bringt von Haus aus einige native Treiber zum Zugriff auf Microsoft Access, Interbase, FoxPro, Paradox etc. mit. Allerdings sind diese Treiber zum größten Teil veraltet und können mit neueren Datenbankformaten nicht mehr umgehen. Deshalb ist in den meisten Fällen nur der Zugriff über ODBC möglich. Die BDE bietet die Möglichkeit auch auf die im System eingetragenen ODBC-DSN (DATA SOURCE NAME) zuzugreifen.

In diesem Kapitel wollen wir exemplarisch den Zugriff auf eine Microsoft Access-Datenbank sowie den Zugriff auf den freien Datenbankserver Firebird darstellen.

ODBC-Treiber

Voraussetzung für den Zugriff auf ODBC-Datenquellen ist ein auf dem Client-PC verfügbarer ODBC-Treiber sowie ein entsprechender ODBC-Eintrag.

Die ODBC-Verwaltung läßt sich entweder in der Systemsteuerung des PC aufrufen, oder über die BDE. In der BDE muss dazu der Reiter Datenbanken (Databases) angeklickt werden. Dann erscheint im Menü Object der Menüpunkt ODBC-Administrator. Auf dem Reiter Drivers werden alle im System installierten ODBC-Treiber aufgelistet.

Auf einem frisch eingerichteten Windows-PC mit einem Officepaket ist normalerweise schon ein kleines Set an ODBC-Treibern installiert. Der wichtigste für uns dürfte der Microsoft-Access Treiber sein.

Microsoft Access-Treiber (*.mdb) Microsoft Access-Driver (*.mdb)

Die beiden o.g. Treiber sind eigentlich identisch und haben normalerweise auch die gleiche Treiberversion. Der eine ist für englische Systeme, der andere für deutsche. Welcher in der Anwendung verwendet wird, ist völlig egal, da die Spracheinstellungen in der BDE eingestellt werden. Es muss dabei nur darauf geachtet werden, dass die in der BDE eingestellte Sprache auch der Sprache der Tabelle entspricht. Im Normalfall ist das bei deutschen Access-Tabellen "'WEurope' ANSI".

Weitere Treiber lassen sich beliebig nachinstallieren. Allerdings gibt es auch kostenpflichtige ODBC-Treiber, bei denen die entsprechenden Lizenzbedingungen beachtet werden müssen. In diesem Kapitel wollen wir außer dem Access-Treiber noch den ODBC-Treiber für den OpenSource-Datenbankserver Firebird behandeln, der kostenfrei erhältlich ist unter http://firebird.sourceforge.net/index.php?op=files&id=odbc .

Nach der Installation existiert in der OBDC-Treiberliste ein Eintrag

Firebird/InterBase(r) driver

ODBC-DSN-Eintrag erstellen

Um auf eine ODBC-Datenquelle zugreifen zu können, muss noch ein sogenannter System-DSN angelegt werden. Dieser wird im ODBC-Administrator unter SYSTEM-DSN mit der Schaltfläche ADD hinzugefügt. Um einen SYSTEM-DSN anzulegen, werden Administrator-Rechte benötigt. Der Zugriff auf einen SYSTEM-DSN kann aber von allen Benutzern erfolgen. Als nächstes folgt die Abfrage des Treibers, der für den neuen DSN verwendet werden soll.

Access-DSN

Hier wählen wir den "Microsoft Access-Treiber (*.mdb)" Treiber. Danach erscheint folgendes Fenster:

Einrichtungs-Dialog Access in ODBC

Mit einem Klick auf "Auswählen" erscheint ein Dialog zur Auswahl der Access-Datei. In unserem Beispiel wurde die Datei "c:\xx\kunden.mdb" ausgewählt. Weitere Konfigurationseinstellungen sind in der Regel nicht notwendig. Wenn Sie OK klicken, erscheint der Eintrag in der SYSTEM-DSN Liste.

Es macht keinen Unterschied, ob es sich um eine *.mdb-Datei im Format Access-95/97 oder Access2000 handelt; das Format wird automatisch erkannt.

Excel-DSN

Über ODBC kann dBASE auch auf Excel-Tabellen zugreifen, und zwar sowohl lesend als auch schreibend.

Als Treiber wählen wir "Microsoft Excel-Treiber (*.xls)" bzw. die englische Version "Microsoft Excel Driver (*.xls)". Diese Treiber sind geeignet für den Zugriff auf Excel-Dateien in diversen Formaten, einschließlich Excel 97 und Excel 2000; dieses Format kann auch von Excel 2003 und Excel 2007 gelesen und geschrieben werden. Für neuere Excel-Versionen (2003, 2007) steht ein weiterer Treiber zur Verfügung namens "Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)", auf den wir hier aber vorerst nicht eingehen.

Im Dialog "ODBC Microsoft Excel Setup" wird der Name der Datenquelle eingetragen, z.B. "EXEL_ODBC". Dann klicken wir auf die Schaltfläche "Arbeitsmappe auswählen" und navigieren zu der gewünschten Excel-Datei, z.B. "c:\Excel\test1.xls". Über die Schaltfläche "Optionen" können wir weitere Einstellungen vornehmen. Hier können wir u.a. angeben ob die Datenbank "Schreibgeschützt" geöffnet werden soll, also für Nur-Lesen-Zugriff. Um auch schreibenden Zugriff auf die Datenbank zu ermöglichen, müssen wir ggf. den Haken aus dem Auswahlkästchen entfernen.

Nach dem Klick auf die Schaltfläche OK erscheint der Eintrag in der SYSTEM-DSN Liste.

Damit der Zugriff auf eine "fremde" Excel-Datei (d.h. eine Datei, die nicht aus dBASE heraus durch einen COPY-Befehl oder Updateset.copy() erstellt wurde) aus dBASE funktioniert, muss außerdem in der Excel-Tabelle selbst für den gewünschten Bereich über das Menü Einfügen > Name > Definieren ein Name vergeben werden. (In Office 2007 müssen wir erst den Datenbereich markieren und dann im Kontextmenü die Option "Bereich benennen" auswählen). Der von uns vergeben Name taucht dann nach dem Öffnen der Datenbank im dBASE-Regiezentrum als Tabellenname auf. Eine Excel-Datei kann mehrere Datenbereiche umfassen, entsprechend können mehrere Namen vergeben werden, die dann in dBASE als unterschiedliche Tabellen erscheinen.

Das Einfügen eines Namens für einen Datenbereich der Excel-Datei kann auch über OLE erfolgen, vgl.

http://de.wikibooks.org/wiki/Programmieren_mit_dBASE_PLUS:_Kommunikation_mit_anderen_Programmen#Namen_definieren

Firebird-DSN

Hier wählen wir den "Firebird/InterBase(r) driver" Treiber. Danach erscheint folgendes Fenster:

Bei den folgenden Einträgen gehen wir davon aus, dass der Firebird-Server auf dem lokalen Rechner installiert ist und die Datenbank auf c:\xx\kunden.fdb liegt. Im Feld "Data Source Name" geben wir in diesem Beispiel den Namen "FIREBIRD_DATENBANK" ein. Im Feld Database wird zuerst der Servername und dann mit einem ":" getrennt die Datenbank eingetragen.

Anmerkung: Die Datenbank kann entweder mit dem kompletten Pfad angegeben werden (dabei muss der physikalische Pfad auf dem Server hier angegeben werden), oder es kann nur ein Alias angegeben werden. Dieser Alias wird auf dem Datenbankserver in einer Datei aliases.conf im Firebird-Verzeichnis gepflegt. Die Verwendung eines Alias ist in jedem Fall zu bevorzugen, da diese den Umzug einer Datenbank auf dem Server ermöglicht ohne an den Clients eine Änderung vornehmen zu müssen. Bei Verwendung eines Alias würde für unser Beispiel nur der Eintrag "localhost:kunden" stehen und in der Datei aliases.conf eine Zeile "kunden = c:\xx\kunden.fdb" stehen

In unserem Beispiel haben wir die Datenbank auf dem lokalen Rechner und tragen deswegen "localhost:c:\xx\kunden.fdb" ein. Im Feld "Character Set" tragen wir den Sprachtreiber "WIN1252" ein. Diese Einstellung ist abhängig davon, mit welchem Sprachtreiber die Firebird-Datenbank erstellt wurde. Die restlichen Felder können leer bleiben. (Wenn jedoch eine automatische Anmeldung an der Datenbank erfolgen soll - wozu ich nicht rate - können hier die Benutzerdaten eingetragen werden.)

MSSQL-DSN

Beschreibung wird noch erstellt.

ODBC-Eintrag in der BDE

Nachdem die SYSTEM-DSN erstellt wurden, erscheinen in der BDE die beiden Einträge als normale Datenbank-Aliase. Meistens ist es notwendig den BDE-Abministrator noch einmal neu zu starten, damit die Einträge vorhanden sind. Wenn trotz eines Neustarts des BDE-Administrators die ODBC-Einträge nicht sichtbar sind, prüfen Sie ob im BDE-Administrator unter Konfiguration/System/INIT die Einstellung "AUTO ODBC" auf true gesetzt ist. Danach müssten die Einträge sichtbar sein.

Der erstellte Access-Eintrag sieht dann folgendermaßen aus:

ODBC-Alias in der BDE für Access

Oben unter "TYPE" ist der Treiber zu sehen und unter "ODBC DSN" der entsprechende Eintrag. Normalerweise ist der Eintrag für "LANG DRIVER" leer. Hier wurde noch der Treiber "'WEurope' ANSI" manuell nachgetragen, da es sich um eine Tabelle mit entsprechenden Sprachtreiber handelt.

Analog dazu der Eintrag für die Firebird Datenbank.

Anmerkung: Bei Verwendung von BLOBS (MEMO-Feldern) oder großen Textfeldern (VARCHAR) ist der Wert für "BLOBS TO CACHE" hoch zu setzen. Ein Wert von "20000" ist hier durchaus sinnvoll. Es kann sonst bei Abfragen mit solchen Feldern zu Laufzeitfehlern kommen.

Zugriff aus dBase auf ODBC-Datenquellen

Nachdem die beiden Aliase im ODBC-Administrator angelegt wurden und in der BDE entsprechend angepasst wurden steht einem Zugriff auf die Daten nichts mehr im Weg.

Die Datenbank-Aliase stehen im Regiezentrum oder für Anwendungen wie alle anderen Aliase zur Verfügung. Bei der Auswahl des Alias kann, je nachdem wie die Einstellungen für die Quelldatenbank ist, ein Dialog zur Passwortabfrage erscheinen. Hier muss der entsprechende Benutzer und das Passwort für den Zugriff auf die Datenbank eingetragen werden. Um in Anwendungen diese Passwortabfrage zu vermeiden, kann in einem DATABASE-Objekt die Eigenschaft "loginString" gesetzt werden. Der Wert wäre hier der Benutzername, dann einen "/" und das Passwort: "benutzer/passwort".

Automatische Erstellung eines ODBC-BDE-Alias

Spätestens wenn geplant wird eine Anwendung mit Hilfe eines Installationsprogramms weiter zu geben, tritt das Problem der automatischen Erstellung von BDE-Aliasen auf. Schließlich soll die Anwendung beim Kunden auch funktionieren, ohne dass noch eine Anpassung vom Entwickler vorgenommen werden muss. Bei Installation mit einem SQL-Server wird zwar oft der SQL-Server (z.B. Firebird) vom Entwickler installiert, und auch die ersten Arbeitsplätze fertig eingerichtet. Aber der Kunde will ja nicht jedesmal den Entwickler bemühen, wenn ein neuer Rechner eingerichtet wird. Aus diesen Gründen ist es sinnvoll, eine Routine zu haben, die einen BDE, oder ODBC-Alias programmgesteuert erstellen kann.

Für BDE-Aliase gibt es in der dUFLP eine bdealias.cc mit der ein nativer Eintrag für einen BDE-Alias erstellt werden kann.
Für ODBC-Aliase gibt es in der dUFLP ein createODBC.prg mit der ODBC-Einträge erstellt werden können.

Beide Funktionen sind in den Quelltexten vorhanden und kurz in ihrer Verwendung beschrieben.

Zurück zu Inhaltsverzeichnis |

Hoch zu Regal EDV |

Vor zu Inhaltsverzeichnis