ODBC für Datenbankneuling

[Frederika]

Hallo allerseits! Kurz vorweg: Ich mache sehr viel in Delphi, aber habe leider noch NIE Datenbanken benötigt. Jetzt ist es soweit. *seufz* Es geht um ein biologisches Projekt und unser bereits recht umfangreiches Programm soll nun plötzlich auch auf eine fremde Datenbank eines Kooperationspartner zugreifen können, für das die EDV-Leute dort eine "ODBC-Schnittstelle zur Verfügung stellen werden". Wir müssen dann nur "die stored procedure aufrufen" und "erhalten passende Ergebnistabellen zurück". Ha, klingt so simpel, aber ich weiß nicht mal, wo ich anfangen soll. Letztlich möchte ich die sogenannte Ergebnistabelle einfach zellenweise auslesen und in eigene Objektstrukturen überführen.

Wir verwenden hier noch Delphi 6 (Win32) und das soll aufgrund der Größe des bereits bestehenden Projekts auch so bleiben. Der Zugriff sollte möglichst performant sein, da es wohl ziemliche Datenmengen und häufige Zugriffe sein werden.

Welche Komponenten sind empfehlenswert? BDE? ADO? Wie fängt man an? Wäre wirklich dankbar für eine Einsteigerbeschreibung. Soll so simpel wie möglich sein, ist halt erstmal nur der Datenimport.

Noch eine Frage: Was ist eine ODBC-Schnittstelle? Kann man das, was wir gesagt kriegen werden, einfach als Dateinamen in das TQuery.DatabaseName Feld eintragen? Oder wie muss man sich das praktisch vorstellen? Kann ein ODBC beliebig viele Tabellen verwalten?

Grüße,
Frederika

[Bernhard Geyer]

Wenn ihr wirklich einen vollwertigen ODBC-Treiber bekommt gibt es zwei möglichkeiten:

a, Zugriff über ADOExpress. Dazu muß der ODBC-Treiber einen bestimmten Level erreichen. Am besten Nachfragen ob der Zugriff über ODBC möglich wäre.

b, Native ODBC-Zugriffskomponenten.

BDE ist kein Alternative da diese Entwicklungstechnisch gestorben ist und auch der Wissensgrad von vielen User bei Delphi auch schon Nahe 0 liegt.

[Frederika]

Hallo Bernhard,
danke für die schnelle erste Antwort. Nun, ich gehe davon aus, daß uns dort eine ODBC-Schnittstelle erwartet -- ob nun Treiber oder wie auch immer das funktioniert.

OK, BDE ist also veraltet und sollte nicht mehr genommen werden.

ADO dagegen ist noch aktuell? Ist das performant genug für die heutige Zeit oder auch schon am veralten?

Was meinst Du mit "nativen ODBC-Zugriffskomponenten"? Ich habe bei der zwischenzeitlichen Websuche das hier gefunden: http://www.softvector.com/products/odbcdac/index.htm -- ist aber kostenpflichtig, wenn auch günstig. Hat da jemand Erfahrung mit?

Ich habe inzwischen etwas mit TDataSet, TQuery und so gespielt, aber muß wirklich sagen, daß die Delphi-Hilfe auf diesem Gebiet mehr als miserabel ist. Nun gut, ich habe ja Euch! :-)

Grüße,
Frederika

[mkinzler]

Ado ist die Nachfolgetechnik von ODBC.
Der Ado-Wrapper von Delphi bietet die VCL-typischen Zugriffstechniken

http://www.delphi-treff.de/tutorials/datenbanken/

[Frederika]

ADO ist Nachfolger, aber auch kompatibel zu ODBC? Oh Mann, diese Abkürzungen! ;-) Ich habe es bei Wikipedia so verstanden, dass ADO gerade ODBC nutzt, also sozusagen die lokale Schnittstelle ist, um auf ODBC zuzugreifen. Hm...

Ich möchte dafür die für mich einfachste Art nehmen, aber dennoch möglichst sehr performant. (Klar, läßt sich nicht unbedingt beides erreichen...) Ist ADO denn uneingeschränkt empfehlenswert für den Zugriff auf ODBC?

[mkinzler]

Ado besitzt einen Treiber für ODBC, welcher dann den vorhandenen spezifischen ODBC-Treiber verwendet. Da ADO ein Superset von ODBC ist, sollte es keine Probleme geben.

[Bernhard Geyer]

Zitat von Frederika:

danke für die schnelle erste Antwort. Nun, ich gehe davon aus,... wie auch immer das funktioniert.

Zweckoptimist

OK, BDE ist also veraltet und sollte nicht mehr genommen werden.

Zitat von Frederika:

ADO dagegen ist noch aktuell? Ist das performant genug für die heutige Zeit oder auch schon am veralten?

ADO ist für Win32 und manche Datenzugriffe sehr gut geeignet.

Zitat von Frederika:

...ist aber kostenpflichtig, wenn auch günstig. Hat da jemand Erfahrung mit?

Evtl. wäre ZEOS geeignet.

Zitat von Frederika:

Ich habe es bei Wikipedia so verstanden, dass ADO gerade ODBC nutzt, also sozusagen die lokale Schnittstelle ist, um auf ODBC zuzugreifen. Hm...

Du kannst mit ADO auch auf ODBC zugreifen. Besser ist es aber direkt einen speziellen ADO-Provider zu haben um einen Umweg über ODBC zu erspraren.

Zitat von Frederika:

Ich möchte dafür die für mich einfachste Art nehmen, aber dennoch möglichst sehr performant. (Klar, läßt sich nicht unbedingt beides erreichen...) Ist ADO denn uneingeschränkt empfehlenswert für den Zugriff auf ODBC?

Definitv nein. Wenn du z.B. MySQL oder Oracle hat ist es besser native Zugriffskompos zu verwenden. Was ist wohl mit weniger Fehlern verbunden:

Anwendung -> ADOExpress -> ADO -> OLE/DB for ODBC-Treiber -> ODBC -> ODBC-Treiber für MySQL -> MySQL-Datenbank

oder

Anwendung -> native Zugriffskompo -> MySQL-Datenbank

?

[Frederika]

Zitat von Bernhard Geyer:

Zweckoptimist

Absolut, ja. Eigentlich beschäftige ich mich mit Molekülinteraktionen und der neue (und eher unerwartete) Datenimport muß einfach nur erledigt werden... :-)

Zitat:

Du kannst mit ADO auch auf ODBC zugreifen. Besser ist es aber direkt einen speziellen ADO-Provider zu haben um einen Umweg über ODBC zu erspraren.

Nun, ich werde mal fragen, ob es auch eine ADO-Schnittstelle gibt, aber ich schätze, dass ich an ODBC nicht vorbeikomme.

Zitat:

Anwendung -> ADOExpress -> ADO -> OLE/DB for ODBC-Treiber -> ODBC -> ODBC-Treiber für MySQL -> MySQL-Datenbank

Anwendung -> native Zugriffskompo -> MySQL-Datenbank

Verstanden. Sehe ich auch so. Ich glaube, daß die Partner mit ODBC ihr riesiges Datenbanksystem schützen wollen und einfach standardmäßig ODBC bereitstellen. Ich sag es mal so: Ich habe wahrscheinlich keine Wahl.

Also heißt es für mich jetzt erstmal: ADO. Ich lese schon den ganzen Abend alle möglichen Hilfetexte und Tutorials, aber es erscheint doch eher verwirrend.

Ich muß jetzt erst einmal eine lokale Fassung eines ODBC zum Laufen bringen, damit ich dann alles testen kann und später nur diesen ominösen ConnectionString austauschen muß. Gibt es irgendwo eine Step-By-Step-Anleitung, wie man aus einer Exceltabelle oder Access-Datenbank einen ODBC-Zugriff zaubern kann? (so daß für Delphi alles wie "richtiges" ODBC aussieht?)

[sx2008]

Zitat von Frederika:

Ich muß jetzt erst einmal eine lokale Fassung eines ODBC zum Laufen bringen, damit ich dann alles testen kann und später nur diesen ominösen ConnectionString austauschen muß. Gibt es irgendwo eine Step-By-Step-Anleitung, wie man aus einer Exceltabelle oder Access-Datenbank einen ODBC-Zugriff zaubern kann? (so daß für Delphi alles wie "richtiges" ODBC aussieht?)

Infos über den ConnectionString gibt es hier: http://www.connectionstrings.com
Um welchen Datenbankhersteller (Oracle, IBM DB2, MySQL, SAP DB, ...) handelt es sich überhaupt?
Das muss immer die erste Frage sein, wenn man eine fremde Datenbank anbinden soll.

[globetrotter77]

Zitat von sx2008:

Um welchen Datenbankhersteller (Oracle, IBM DB2, MySQL, SAP DB, ...) handelt es sich überhaupt?
Das muss immer die erste Frage sein, wenn man eine fremde Datenbank anbinden soll.

Da muss ich sx2008 recht geben!

ODBC hat zwar dieses schöne O für Open in der Abkürzung, was auch wie eine runde Sache aussieht, aber ganz so einfach ist es in der Regel eben doch wieder nicht.

Also erst mal herausfinden, um welche DB es sich handelt, dann kann man weitersehen.

Danach brauchst du vermutlich die Informationen über Zugriffsberechtigungen etc., weil ja nicht jeder alles lesen darf.

Erste Aktion wäre dann, die Connection zur DB aufzubauen und zu testen.
Erst wenn das geklappt hat, kannst du versuchen, auf eine konkrete Tabelle zuzugreifen.
Wenn auch das funktioniert, wird es ganz einfach!

Die Simulation über Excel oder Access hilft meiner Erfahrung nach überhaupt nicht weiter, da würde ich kein Gehirnschmalz reinstecken!

Aber keine Angst, in der Regel lässt sich wirklich jede DB anzapfen.