Die Schnittstellensoftware ist hier Teil des Betriebssystem.
..snip..
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!)
..
Widerspricht sich das nicht?
Treiber hin oder her, ich müsste auch für andere Systeme Treiber installieren (außer meine Delphikomponenten machen das nativ).
Access halte ich aus diversen Gründen für "exotisch" und nicht naheliegend, weder für Anfänger noch Fortgeschrittene. Naheliegendere Systeme sind nur ein paar Klicks entfernt.
Ja, der Widerspruch ist vorhanden, aber man kann leicht prüfen, ob's nun funktionieren wird oder nicht.
Access ist exotisch, wenn man es aus der Sicht der gleichnamigen Software von MS sieht. Die ist meiner Meinung nach ein Graus.
Nimmt man nur "normales"
SQL, dass auch gegen jede andere Datenbank läuft, dann ist die Datenbankdatei einfach nur 'ne Datenbankdatei. Man merkt aus dem Programm heraus (egal ob als Anwendern oder Entwickler) nicht, dass da ein (wie Du sagst) Exot hinter hängt.
Welches sind bitte die "Naheliegenderen Systeme, die nur ein paar Klicks entfernt sind?"
Was muss der Laie tuen, um eine funktionierende Datenbankanwendung schreiben zu können?
Wo muss z. B. bei SQLite die
DLL hin?
Wie sieht es bei embedded FireBird aus?
Kann man deren Schnittstellen ggfls. auch zeitgleich für mehrere Programme, aber unterschiedliche Datenbanken nutzen?
Kann eine Datenbank von mehreren Programmen zeitgleich genutzt werden?
Und mir ist klar: Für professionelle Software ist mein Vorschlag absoulut ungeeignet.