Die Schnittstellensoftware ist hier Teil des Betriebssystem. Sie ist genauso sicher oder unsicher, wie z. B. alle Aufrufe der Windows-
API. Es hat bisher funktioniert, aber muss es nicht für immer und alle Zeiten.
Deshalb kann man ja z. B. aktuelle Delphis nicht mehr auf älteren Windosen installieren.
Das Problem habe ich immer. Niemand kann mir garantieren, dass ich mit einem aktuellen FireBird (embedded) für immer und alle Zeiten eine heute geschriebene Software auf allen weiteren Windosen, die es noch so geben wird, nutzen kann. Dergleichen gilt auch für SQLite oder eine Delphiexe, die mit den heute aktuellen Datenbankkomponenten für den Zugriff auf z. B. Oracle geschrieben wurde.
Das beschriebene Problem
Zitat von
p80286:
Und ob Du
ODBC oder eine andere Schnittstelle nutzt, eine
DLL oder EXE ist immer im Spiel. Es kann sein, daß Du nichts explizit dazu laden mußt, aber ohne geht es nicht. Du brauchst immer eine Schnittstellensoftware und sei sie selbst geschrieben!
habe ich immer. Ich brauche immer irgendwas, was zwischen meiner Applikation und der Datenbank "hängt". Egal ob ich jetzt eine
DLL mitliefere (z. B. SQLite) oder mehrere (z. B. Embedded FireBird) oder über
ADO auf
Access zugreife oder sonstwie auf welche Datenbank auch immer.
Immer laufe ich Gefahr, dass früher oder später Änderungen an der Schnittstelle und/oder am Betriebssystem eine weitere Nutzung meiner Software verhindern.
Unabhängig von der Schnittstelle: Ich weiß nicht, ob eine heute erstellte Exe mit aktuellem Delphi und aktuellem Windows, in Zukunft weiterhin auf neuer Hardware und/oder neuem Windows funktionieren wird. Es ist eher davon auszugehen, dass dem nicht so sein wird.
Bei (übertrieben) konsequenter Beachtung des oben zitieren Einwandes, wäre von der Nutzung einer Datenbank abzuraten. Es besteht immer potentiell die Möglichkeit, dass es irgendwann nicht mehr funktioniert, weil Änderungen am Betriebssystem und/oder der genutzten Datenbankschnittstelle eine weitere Funktion verhindern. Letztlich sollte man dann auch keine eigene Software erstellen, da auch hier nicht sichergestellt werden kann, dass sie für alle Zeiten auf neuen Rechnern und neuen Betriebssystemversionen funktionieren wird.
Selbst bei der Nutzung von Fremdsoftware hat man keine Garantie, dass man diese immer und für alle Zeiten nutzen kann.
Einen Tod muss man sterben.
Und wenn man gut programmiert, dann baut man sich in die Datenbankanwendung eine Exportfunktion für die Daten ein und ebenso eine Importfunktion. Damit kann man dann schonmal für Datensicherungen ausserhalb der Datenbank sorgen. Dies halte man bitteschön
SQL-Standardkonform.
Sollte es die Unterstützung der genutzten Datenbank nicht mehr geben, ändert man das Programm auf die Nutzung einer anderen Datenbank, was mit den aktuellen Datenbankkomponenten kein wirkliches Problem sein sollte, nimmt den letzten Datenexport und importiert ihn in eine neue, andere Datenbank (beliebiger Hersteller) und kann die Software weiter nutzen.
@Jobo:
Egal welche Datenbank: Halte mich an den
SQL-Standard, dann sind exotische Sonderlocken diverser Datenbanksystem nicht von belang.
Tabelle erstellen kann man halt mit reinem
SQL. Wenn ich FireBird (embedded) oder SQLite nutze, hab' ich ja auch nicht sofort irgendeine komfortable Oberfläche. Für mich ist
Access nichts weiter als eine Schnittstelle zu einer Datenbankdatei. Bisher ist sie bei Windows meist dabei. Bei SQLite und FireBird muss ich mich halt selbst drum kümmern.
Rein aus Programmquelltextsicht besteht für mich da kein Unterschied. Man nehmen (z. B. die Zeos-Komponenten oder was man immer auch nutzen möchte), sage der, welche Datenbank sie zu gefälligst zu nehmen habe und gut ist.
So wie
Access SQL-technische Besonderheiten hat, haben es FireBird und SQLite auch. MS-Server und Oracle sind auch nicht vollumfänglich kompatibel, noch
MySQL und Postgres (und was weiß der Geier noch) dazu und irgendwie passt nix mehr so ohne weiteres zusammen.
Fazit: Egal, was man hier jetzt empfiehlt: Für jeden Lösungsvorschlag finden sich sehr schnell eine Reihe fundierter und berechtigter Gegenargumente.
Mein Vorschlag für
Access: Meist schon vorhanden (beim eigenen Rechner schnell prüfbar - sprich: kann man 'nen
ODBC-Treiber für MS-
Access anlegen? Wenn nein: Vergiss es!) und für den Anfänger zur Erstellung der ersten Datenbankanwendung erstmal vollkommen ausreichend. Einmal Datenbankdatei erstellen und dann mit Delphi das Programmieren einer einfachen Datenbankanwendung lernen. Wenn man dass dann kann und sich irgendwann mit Datenbanken auskennt, sollte ein Umstieg auf eine beliebige "professionelle" Datenbank dann kein Problem sein.
Für eine Unternehmenssoftware jedoch sicherlich eher induskutabel.