![]() |
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! |
Re: Datenbank-Hersteller neutral programmieren mit ADO
Hallo,
Zitat:
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 |
Re: Datenbank-Hersteller neutral programmieren mit ADO
Jetzt kann ich wieder meinen Liebling Anbringen:
![]() In der konkrenten Implementierungsklasse nimmst du für Access und MS SQL Server ADO, für MySQL und Oracle die Komponenten von DevArt. |
Re: Datenbank-Hersteller neutral programmieren mit ADO
Hast Du es schon mal mit
SQL-Code:
probiert?
SELECT Name FROM Personen
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. |
Re: Datenbank-Hersteller neutral programmieren mit ADO
SQL-Code:
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 :/
SELECT Name FROM Personen
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? |
Re: Datenbank-Hersteller neutral programmieren mit ADO
Dann muss aber eine entsprechende JET installiert sein. Ich würde besser FireBid embedded oder SqLite verwenden
|
Re: Datenbank-Hersteller neutral programmieren mit ADO
Zitat:
Zitat:
|
Re: Datenbank-Hersteller neutral programmieren mit ADO
Zitat:
Bernd. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:47 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz