Da ich vom Post-Ersteller auch als Theoretiker difarmiert wurde hier meinen Senf:
1, Unsere Anwendung (welche auch bei Mrd-€-Unternehmen eingesetzt wurde) bedient ebenfalls mehrere
DB's (MS
SQL-Server, Oracle,
MySQL und eine Desktop-
DB). Diese hat früher die Server-Datenbanken ebenfalls per
BDE angesprochen. Aufrund vieler Probleme mit der
BDE wurde zuerst Oracle auf einen nativen Zugriff umgestellt (vor meiner Zeit). Nach einiger Zeit wurden auch MS
SQL-Server (auf
ADO-Native) und abschließend
MySQL umgestellt und haben seitdem nur noch die "üblichen" Probleme mit dem Zugriff: Firewall, Portfreigaben, Benutzerrechte, ... Ein großer Vorteil ist das unsere Anwendung ohne die üblichen (problematischen)
ODBC und Client-Installationen auskommt. Wir können zwar nicht sagen wieviel uns das pro Jahr spart, jedoch sind die Aufwände in dem Bereich Clientinstallation praktisch auf 0 gefallen. Ach ja: Sollte jemand die myodbc-installation in einer Closed-Source-Anwendung auf seine Installations-CD packen, so muß er entweder für jede Installation eine
MySQL-Server-Lizenz kaufen oder sich einen Firmenlizenz anschaffen (ca. 40.000 € pro Jahr).
2, Eine Unterstützung von mehreren
DB's in einer Anwendung benötigt keine
BDE (oder
ADO) sondern eine vernünftige Kapslung mittels z.B. Bridge-Pattern. So habe ich es z.B. geschafft innerhalb 2 Tage einen port nach SQLite durchzuführen.
3, Mein vormaliges vorhandes
BDE-Spezial-Wissen ist mitlerweile ziemlich auf 0 gefallen (Querwissen eher von der eingesetzten Desktop-
DB bezüglich SetRange-Performancevorteile). Unglücklicherweise haben wird noch ein Internes Tool welches noch auf
BDE aufsetzt und immer wieder bei neuen PC's probleme bereitet (Installation + Sonderzeichen) aber aufgrund Zeit+Prioritätsmangel noch nicht umgestellt wurde.
4, Wer heute noch
Paradox problemlos einsetzt muß sehr viel Glück haben. Ich hate (vor ca. 5 Jahren) das vergnügen eine SW eines Versicherungskonzerns kurzzeitig benutzen zu dürfen (Eingaben von Flächen + Nutzungangaben). Nach 5 Eingaben war die Datenbank jedesmal zerschossen. Hatte auch noch Kontakt mit dem Entwickler und es schien mir das selbst
BDE-Entwickler trotzt fertigen Programms nicht zwangsläuftig genügend Spezialwissen besitzen müssen programmtechnisch zu umschiffen.
5, Zu meinem Post mit: „Jedoch ist
BDE nur noch für Anwendungen die den "End of Life" erreicht haben zu akzeptieren.
Ich war in einer Firma in der man auch keine Neuentwicklung (mit neuer Technik) durchführen wollte. Es kamen zwar noch Jahrelang vom Hauptkunden immer wieder größere Aufträge aber das Kernsystem durfte nicht redesigned werden. Dann gabe es vom Hauptkunden keine neuen Aufträge und die Firma mußte da sie mit dieser veralteten Technik keine Neukunden gewinnen konnte (Konkurenzprodukte hatten mit neuerem Technologieansatz offensichtliche Vorteile) Mitarbeiter (auch Entwickler) entlassen. Ich hätte zwar noch weiterarbeiten können, hatte aber schon neuen Job.
6 Zu deiner Folgerung:
Zitat:
Da beherrschst Du die
BDE, kommst Du auch ohne
BDE blitzschnell zu Recht – ABER leider NICHT umgekehrt, da
BDE wirklich Probleme bereitet…
Genau deshalb sollte man auch bei bestehenden Projekten die
BDE entsorgen wenn diese noch einige Jahre im Einsatz sind bzw. verkauft werden sollen. Bei
SQL Datenbanken gibt es noch genügend Know-How-Felder die man sich aneignen kann, da sollte die Zugriffschicht nicht auch noch Probleme verursachen.