Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Delphi Datenbank-Hersteller neutral programmieren mit ADO (https://www.delphipraxis.net/121306-datenbank-hersteller-neutral-programmieren-mit-ado.html)

berens 25. Sep 2008 12:49

Datenbank: Möglichst Jede • Zugriff über: ADO

Datenbank-Hersteller neutral programmieren mit ADO
 
Hi!

Ich würde gerne mein nächstes Projekt so entwickeln, dass es mit jeder Datenbank zurecht kommt, die mit ODBC / OLEDB / ADO angesprochen werden kann (z.B. MSSQL, MYSQL, Access, etc., keine Exoten).

Bisher klappt das ja generell, dass ich mich mit dem passenden ConnectionString auf die Datenbanken verbinde, soweit kein Problem.

- Wenn ich aber z.B. mit einer Access-Datenbank arbeite, klappen manche Befehle nicht, die laut SQL-Standard 1992 funktionieren sollen.
- SELECT "Name" FROM Personen geht nicht bei allen Datenbanken (" wird nciht unterstützt)
- SELECT Name FROM [Personen] geht nicht bei allen Datenbanken ( [ ] werden nicht unterstützt

etc. Das sind so die kleinen Probleme, weshalb mein Programm noch nicht ausserhalb von Access benutzt werden kann.

Gibt es nun eine Möglichkeit, wie ich mit TAdoDataset oder wie auch immer mit einem SQL-Befehl oder Filter von allen Datenbanken die korrekten Datensätze bekomme?

Hat jeman deinen Link oder weiterführende Infos zum dem Thema Datenbankhersteller-unabhängige Programmierung?

Danke im Vorraus!

nahpets 25. Sep 2008 13:40

Re: Datenbank-Hersteller neutral programmieren mit ADO
 
Hallo,
Zitat:

Ist datenbankherstellerunabhängige Programmierung möglich?
klare Antwort: Nein

SQL ist standardisiert: Soweit die Theorie.

Praktisch gibt es dort teils gigantische Unterschiede.

Mir ist bis jetzt nur ein Mittel eingefallen:

SQL's in eine Datenbanktabelle schreiben und aus dieser Tabelle in die Query laden und ggfls. über die Parameter mit Werten versehen.

Wenn Du nun die Datenbank wechselst, musst Du nur die nicht kompatiblen SQL's in der Datenbanktabelle ändern, brauchst aber nicht an Dein Programm. Auch eine eventuell erforderliche Fehlerkorrektur an SQL's führt nicht zwingend zu einer Änderung am Programm.

Das einzige feste SQL, das Du in Deinem Programm brauchst, ist das zum Auslesen der SQL's. Dies sollte aber datenbankübegreifend funktionieren.

Mit dieser Methode kannst Du ein Programm bei verschiedenen Kunden gegen unterschiedliche Datenbanken laufen lassen, ohne eine entsprechende Anzahl von Progammversionen pflegen zu müssen.

Stephan

Bernhard Geyer 25. Sep 2008 13:43

Re: Datenbank-Hersteller neutral programmieren mit ADO
 
Jetzt kann ich wieder meinen Liebling Anbringen: Bridge-Pattern
In der konkrenten Implementierungsklasse nimmst du für Access und MS SQL Server ADO, für MySQL und Oracle die Komponenten von DevArt.

HeikoAdams 25. Sep 2008 13:43

Re: Datenbank-Hersteller neutral programmieren mit ADO
 
Hast Du es schon mal mit
SQL-Code:
SELECT Name FROM Personen
probiert?

Wenn Du Hersteller neutral programmieren willst, musst Du Dich auf einfachste SQL Abfragen beschränken, Sichten und StoredProcedures meiden etc. Also sehr aufwändig programmieren. An Deiner Stelle würde ich mich daher auf MySQL und/oder MSSQL konzentieren. Access würde ich vernachlässigen, da das Teil IMHO eine Krankheit ist und kein Datenbanksystem.

berens 25. Sep 2008 13:48

Re: Datenbank-Hersteller neutral programmieren mit ADO
 
SQL-Code:
SELECT Name FROM Personen
geht leider nicht immer, weil z.B. Tabellennamen unter Umständen Schlüsselwörter der einzelnen Datenbanksysteme sein können. Da bekommt man dann z.B. ne Meldung wie "Ungültiger SQL-Befehl "Name" oder sowas. Leider kann ich die Spaltennamen nicht immer selbst bestimmen :/

Access nur deswegen, weil das im Moment die beste Möglichkeit für mich ist, auf einem lokalen System ohne DB-Server zu Arbeiten. Und ich brauche nur die .mdb Datei, wenn ich dem Kunden eine neue DB zusende...


Eine TAdoTable repräsentiert doch ansich gut jeweils eine Tabelle aus der Datenbank. Ist es möglich, TAdoTable übergreifen eine (z.B. Inner Join) Abfrage zu machen?

mkinzler 25. Sep 2008 17:47

Re: Datenbank-Hersteller neutral programmieren mit ADO
 
Dann muss aber eine entsprechende JET installiert sein. Ich würde besser FireBid embedded oder SqLite verwenden

Bernhard Geyer 25. Sep 2008 17:50

Re: Datenbank-Hersteller neutral programmieren mit ADO
 
Zitat:

Zitat von berens
SQL-Code:
SELECT Name FROM Personen
geht leider nicht immer, weil z.B. Tabellennamen unter Umständen Schlüsselwörter der einzelnen Datenbanksysteme sein können. Da bekommt man dann z.B. ne Meldung wie "Ungültiger SQL-Befehl "Name" oder sowas. Leider kann ich die Spaltennamen nicht immer selbst bestimmen :/

Deshalb Bridge-Pattern. Damit kannst du Tabellennamen entsprechen Quoten.

Zitat:

Zitat von berens
Eine TAdoTable repräsentiert doch ansich gut jeweils eine Tabelle aus der Datenbank. Ist es möglich, TAdoTable übergreifen eine (z.B. Inner Join) Abfrage zu machen?

Dafür nimmt man TADOQuery oder TADODataset.

aladin60 26. Sep 2008 17:01

Re: Datenbank-Hersteller neutral programmieren mit ADO
 
Zitat:

Zitat von berens
SQL-Code:
SELECT Name FROM Personen
geht leider nicht immer, weil z.B. Tabellennamen unter Umständen Schlüsselwörter der einzelnen Datenbanksysteme sein können. Da bekommt man dann z.B. ne Meldung wie "Ungültiger SQL-Befehl "Name" oder sowas. Leider kann ich die Spaltennamen nicht immer selbst bestimmen :/

Access nur deswegen, weil das im Moment die beste Möglichkeit für mich ist, auf einem lokalen System ohne DB-Server zu Arbeiten. Und ich brauche nur die .mdb Datei, wenn ich dem Kunden eine neue DB zusende...


Eine TAdoTable repräsentiert doch ansich gut jeweils eine Tabelle aus der Datenbank. Ist es möglich, TAdoTable übergreifen eine (z.B. Inner Join) Abfrage zu machen?

Vorschlag: nimm z.B. MSSQL, mache von der neuen DB ein Backup (SQL-Befehl) und integriere in Dein Programm das RESTORE. Dann kann weiterhin dem Kunden "eine neue Datenbank geliefert" werden.

Bernd.


Alle Zeitangaben in WEZ +1. Es ist jetzt 16:02 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz