Native DB Ansteuerung (ohne BDE?)

[Phoenix]

Hi Leute,

eine Frage, die vielleicht trivial aussieht, es aber sicher nicht ist:

Wie kann ich verschiedene Datenbanken Native mit meinem Programm OHNE den Umweg über BDE / ODBC zu machen ansteuern?

Ich denke, es müsste da freie (open source?) Komponenten geben, habe aber in der Richtung noch nichts passendes gefunden :(

Was mir vorschwebt ist eine Komponente zu schreiben, der ich über bestimmte Parameter sage, welche DB sie anzusteuern hat, und das Programm nur noch über diese eine Komponente direkt mit der DB kommuniziert. Somit wäre es also für mich möglich eine Anwendung zu schreiben, der es egal ist, ob eine BDE installiert ist und ob da nun irgendwo MySQL oder Interbase oder Oracle oder MS SQL Server läuft.

Hat da jemand vielleicht ein- oder zwei Links für mich? ;-)

Vielen Dank,

Sebastian

[Alfons_G]

:hi:
Um eine Datenbank ohne einen dazwischengeschalteten Treiber anzusteuern, muss man wissen, was für eine Datenbank es ist. Da in diesem Fall keine BDE oder dergleichen die Übersetzungsarbeit abnimmt, benötigst Du in diesem Fall Komponenten, welche direkt auf die jeweilige DB zugreifen.

Es gibt Freewarekomponenten für dBase, Paradox, mySQL, Interbase, Access, Oracle und etliche weitere Datenbanken. Du musst dann für alle in Frage kommenden DBs die passenden Komponenten mit einbinden.
Um Resourcen zu sparen, kannst Du für jede Datenbank ein eigernes Datenmodul verwenden und diese Module aus der Liste der automatisch erstellten Formulare rausnehmen. Beim Programmstart fragst Du die verwendete Datenbank ab, dann erzeugst Du das entsprechende Datenmodul. Alternativ kannst Du natürlich auch die Komponenten dynamisch zur Laufzeit erzeugen. :idea:

Alle SQL- und sonstige Manipulationsanweisungen sollst Du dann auch in eigene Funktionen auslagern. Dann gibt Dein Hauptprogramm nur vor, was gemacht wird, wie es gemacht wird, darum kümmert sich die entsprechende Routine. Diese weist Du dann je nach Datenbank zu

Code:

btnInsertOnClick := Daten.MSAccessInsert;
...

:coder:

[Phoenix]

Huhu,

Zitat:

Zitat von Alfons_G

Es gibt Freewarekomponenten für dBase, Paradox, mySQL, Interbase, Access, Oracle und etliche weitere Datenbanken. Du musst dann für alle in Frage kommenden DBs die passenden Komponenten mit einbinden.

Sowas hab ich mir schon gedacht, aber ich habe leider noch keine solchen Komponenten im Netz gefunden. Wahrscheinlich bin ich einfach nur blind oder ich suche an den falschen Stellen :(

Hat mir da jemand vielleicht links zu? Oder noch Hinweise WO ich am geschicktesten nach solchen Kompos suche?

Zitat:

Zitat von Alfons_G

Um Resourcen zu sparen, kannst Du für jede Datenbank ein eigenes Datenmodul verwenden und diese Module aus der Liste der automatisch erstellten Formulare rausnehmen. Beim Programmstart fragst Du die verwendete Datenbank ab, dann erzeugst Du das entsprechende Datenmodul. Alternativ kannst Du natürlich auch die Komponenten dynamisch zur Laufzeit erzeugen.

Ich würde versuchen, die Komponenten, (so sie denn Open Source sind) so weit es geht auf eine gleiche Basis herunterbrechen, so das ich letztlich nur noch ein globales Objekt TApplication.theDataBase habe auf dem dann die Anwendung arbeitet.

Sollten Statementoptimierungen wirklich pro Datenbanktyp nötig sein kann ich den ja dann über dieses Objekt abfragen und ggf. wirklich jeweils DB - Optimierte Funktionen zuweisen.

Die Einstellungen für welche DB usw. würde ich in einer "Art" BDE-Alias auf Registry-Ebene ablegen. So kann man eben verschiedene DB's konfigurieren und auf alle per Auswahl zugreifen. Ich will erstmal weniger eine DB-Anwendung programmieren als überhaupt erstmal in die BD-Materie einsteigen und erstmal den SQL-Explorer nachprogrammieren.

In diesen Sinne bis denne,

Sebastian

[Alfons_G]

Komponenten für den Direktzugriff auf Datenbanken findest Du z.B. bei Torry und bei VCL Components (für Interbase) und VCL Components (für mySQL).
Mit dem Versuch, diese Komponenten an sich funktional anzugleichen, dürftest Du Dir aber etwas viel vorgenommen haben.

Einfacher ist es sicher, die Aufrufe für die einzelnen DBs jeweils in eigenen Funktionen zu kapseln, um eine einheitliche Schnittstelle nach aussen zu haben.

:coder:

[Lemmy]

Hi,

für diesen Zweck hat Borland in Delphi 6 / Kylix die dbExpress eingeführt. Diese soll eine Schnittstelle für SQL-Datenbanken (Interbase, MySQL,...) So einen Treiber kann man auch selbst erstellen, doch das wird vermutlich etwas schwieriger. Dabei verwendet aber dbExpress eine vergleichbare Methode wie die BDE für den Zugriff, auf spezielle Dinge einer Datenbank kann man damit nicht eingehen. Bleibt nur der Weg, der von Alfons_G beschrieben wurde.

Grüße
Lemmy

[Klabautermann]

Hallo,

Zitat:

Zitat von Phoenix

Was mir vorschwebt ist eine Komponente zu schreiben, der ich über bestimmte Parameter sage, welche DB sie anzusteuern hat, und das Programm nur noch über diese eine Komponente direkt mit der DB kommuniziert. Somit wäre es also für mich möglich eine Anwendung zu schreiben, der es egal ist, ob eine BDE installiert ist und ob da nun irgendwo MySQL oder Interbase oder Oracle oder MS SQL Server läuft.

was du da beschreibst ist eine der Grundideen hinter ADO. Du konnectes über den ADO-Treiber auf einen Nativen Datenbanktreiber, welcher natürlich von DB-Hersteller zur verfügung gestellt werden muss. Danach arbeitest du nur noch mit ADO.
Leider funtioniert das in der Praxis nicht so gut, da die einzelnen Datenbanken sich in Leistungsmerkmalen und SQL-Dialekten zu sehr unterscheiden.

Dennoch ist ADO glaube ich Technick, mit der du momentan an dichtesten an deine Wunschvorstellung kommst.

Gruß
Klabautermann

[Phoenix]

Huhu,

eine Statement-Optimierung muss logischerweise beim Generieren des Statements passieren. Das wird sicher nicht in der Funktionalität des Programms sondern im geplanten DBAL (Database abstraction layer) passieren, der zusammen mit der Direct Access - Komponente arbeitet.

ADO ist hier wieder zu sehr auf den Zugriff basierend, als das man hier dann noch sauber zwischen Datenbank und Funktionalität trennen könnte.

Die Baustelle sieht folgendermassen aus und ist in Schichten organisiert:

- Funktionalität arbeitet auf:
- Tabellenobjekt (ggf. verjoined mit anderen Tabellenobjekten): greift zu auf
- Funktionen: Statementoptimierung auf DB-Ebene: verwendet zum ausführen
- Direktzugriff auf die DB - verwendet
- Die geplante Komponente.

Das Ding wird also schon was grösseres :)