Warum nicht BDE?

[Jonas]

Hallo. Wie man hier immer wieder lesen kann ist BDE ja 'outdatet', aber warum genau?
Welche Probleme kann man mit BDE bekommen und warum sollte man es vermeiden?

Ich für meinen Teil benutze BDE für ein Datenbankprojekt nun schon seit knapp einem Jahr und kam bisher damit super klar und hatte nie irgendwelche Probleme oderso. Da ich zur Zeit aber an einem Firmenprojekt arbeite wollte ich mich nochmal genaustens über die Probleme von BDE aufklären.

LG

[Fridolin Walther]

1. BDE ist groß und muss mit ausgeliefert werden. Dabei kommen sich unterschiedliche Versionen von BDE durchaus gerne mal ins Gehege. Wenn Anwendung A also BDE Version X installiert und Anwendung B die BDE Version Y sind Kopfschmerzen vorprogrammiert.

2. Die zu Grunde liegende Architektur der BDE ist stark auf Paradox und dBASE ausgelegt. Ob das ein echter Nachteil ist, ist sicherlich Ansichtssache. Ich fands nie sonderlich angenehm.

3. BLOBs sind ein echtes Problem für viele der BDE Provider.

4. BDE ist ein Layer. Layer verursachen immer Performanceverlust durch unnötigen Overhead. Besonders schlim wirds, wenn sich die Layer übereinander stapeln. Also Du BDE nutzt um auf ODBC zuzugreifen.

5. Auf Grund der Tatsache das BDE ein Layer ist, einigt man sich bei den Funktionen meist auf den kleinsten gemeinsamen Nenner der verwendeten Provider. Das bedeutet, das Features die das Datenbankbackend besitzt, über die BDE nicht nutzbar sind.

6. Die BDE Provider haben teilweise Probleme. Der MS SQL Provider hatte bei mir regelmäßig Probleme wenn es darum ging mehrere Querys parallel durchzuführen, z.B..

[mkinzler]

Zudem wurde die BDE mit Erscheinen von D6 abgemeldet und wird nicht mehr weiterentwickelt. Sie hat zusehens auch Probleme mit neueren Betriebssystemen

[Phoenix]

Die BDE ist 6 Jahre alt und wird seit 6 Jahren nicht mehr weiter entwickelt. Auch Bugfixes gibt es schon seit Jahren nicht mehr.
Zum Beispiel schneidet die BDE ein SQL-Statement nach genau 32k Zeichen ab. Okay, ein 32-k Statement sollte man eigentlich nicht auf eine Datenbank loslassen, aber wenn man halt mal muss, dann geht das mit der BDE nicht. Und das ist nur einer von relativ vielen, bekannten aber weiterhin unkorrigierten Bugs.

Heute auf die BDE zu setzen ist genauso, wie heute noch mit Foxpro eine neue Applikation zu bauen.
Es gibt DbExpress als Nachfolger, und den sollte man am besten auch verwenden.

[Bernhard Geyer]

Bei der BDE müsstest du beim Zugriff auf MS Access die DAO-Komponenten mitliefern (ok, du kannst noch einen größeren Umweg über ODBC machen) welche du nur mitliefernt darfst wenn mindestens ein Programm mit einer MS-IDE erstellt wurde.

Ach ja. Eigentlich sollte mit D2009 gar keine BDE mehr mitgeliefert werden. Ich hoffe aber das mit 64-Bit Delphi/C++-Builder entgültig die BDE gestorben ist.

[hoika]

Hallo,

und neben dem schon gesagtem.

Paradox, DBase (Access) sind File-Datenbanken.
Man benötigt ein Netzlaufwerk (zum Server).
Wenn beim Schreiben mal das Netz kurz weg ist -> Datenverlust.

Ausserdem werden keine Transaktionen unterstützt (cached updates zählt nicht)

Zu Paradox:
mal "index out of date", "blob has been modified" in Google eintippen.


Heiko

[exilant]

Zitat:

Zitat von hoika

Ausserdem werden keine Transaktionen unterstützt (cached updates zählt nicht)

Diese Aussage ist definitiv falsch. Es werden lediglich keine verschachtelten Transaktionen
unterstützt. Mittels SQLLinks ist eine "Starttransacion / Try commit / except rollback" Sequenz kein Problem.
Natürlich nur bei "echten Datenbanken". Bei diesen übernimmt die BDE im Normalfall halt die
Transaktionssteuerung für den Entwickler (Stichwort autocommit). Aber man kann eingreifen.

[mkinzler]

Er hat von den "nativen" BDE-Datenbanken dBase und Paradox gesprochen. Für richtige Datenbanken ist die BDE erst recht nicht zu gebrauchen.
Die Frage sollte eigentlich: "Warum die BDE?" heissen. (dann wäre die Beantwortung kurz)

[exilant]

Zitat:

Zitat von mkinzler

Für richtige Datenbanken ist die BDE erst recht nicht zu gebrauchen.

So? Ich nehme an Du hast da Deine Erfahrungen. Ich kann nur sagen das hier und bei anderen Kunden des Anbieters noch ettliche BDE/SQLLinks Anwendungen mit Sybase und Interbase/Firebird als Backend im 24/7 Betrieb laufen. Und das seit vielen Jahren ohne Probleme. Neue Anwendungen sollten natürlich nicht mit der BDE entwickelt werden, aber das die BDE für C/S DB Anwendungen unbrauchbar wäre ist schlichtweg nicht wahr. Die Praxis beweist das Gegenteil.

[mkinzler]

Vergleiche dann mal die Performance mit Lösungen ohne die BDE. Die Stabilität wird in diesem Fall ja von den DBMS-Servern gewährleistet. Zudem limitiert die BDE die Fähigkeiten der DBMS.

[exilant]

Zitat:

Zitat von mkinzler

Vergleiche dann mal die Performance mit Lösungen ohne die BDE. Die Stabilität wird in diesem Fall ja von den DBMS-Servern gewährleistet. Zudem limitiert die BDE die Fähigkeiten der DBMS.

Die Performance ist OK. Ich habe hier den direkten Vergleich FIBPlus /BDE SQLLinks. Die BDE ist IMO besser/schneller als Ihr Ruf, wenn auch nicht so schnell wie die anderen Zugriffswege. Bei den beiden anderen Punkten hast Du natürlich recht.

[Bernhard Geyer]

Zitat:

Zitat von exilant

So? Ich nehme an Du hast da Deine Erfahrungen. Ich kann nur sagen das hier und bei anderen Kunden des Anbieters noch ettliche BDE/SQLLinks Anwendungen mit Sybase und Interbase/Firebird als Backend im 24/7 Betrieb laufen. Und das seit vielen Jahren ohne Probleme.

Aber du solltest hoffen das die Systemumgebung sich nicht irgendwann mal ändert. z.B. aktueller Firebird auf Windows 2008 und die Clients auf W2008 TS. Ob das dann auch noch läuft ...

Zitat:

Zitat von exilant

... aber das die BDE für C/S DB Anwendungen unbrauchbar wäre ist schlichtweg nicht wahr. Die Praxis beweist das Gegenteil.

Die Praxis zeigt aber auch das mit jedem Windows-Update oder jedem neueren Windows die Probleme mit BDE größer werden. Zwar nicht unbedingt im Serverbetrieb aber der Paradox/dBase-Betrieb wird unter o.g. neuen Systemen fast unmöglich werden.

[exilant]

Zitat:

Zitat von Bernhard Geyer

Die Praxis zeigt aber auch das mit jedem Windows-Update oder jedem neueren Windows die Probleme mit BDE größer werden. Zwar nicht unbedingt im Serverbetrieb aber der Paradox/dBase-Betrieb wird unter o.g. neuen Systemen fast unmöglich werden.

Ich stimme voll und ganz überein. BDE Anwendungen sind Migrationskandidaten bzw.Pflegefälle. Mir ging es in meinen Antworten nicht darum zur BDE zu raten - das Gegenteil ist richtig - sondern nur darum faktisch falsche Aussagen zu zu wiederlegen. Ausdrücklich: Niemand sollte neue Anwendungen mit der BDE entwickeln. Wo immer sich die Zeit findet sollten BDE Anwendungen auf "moderne" Datenzugriffspfade migriert werden. Wie Du sehe ich ein, das für BDE Anwendungen die Uhr immer lauter tickt.
Und was dBase/Paradox angeht: Das sind wirklich Relikte aus einer anderen Zeit.
Das die BDE jedoch für C/S Anwendungen unbrauchbar gewesen sein soll oder für ein ernsthaftes Arbeiten zu buggy - das stimmt einfach nicht.

[Bernhard Geyer]

Zitat:

Zitat von exilant

... - sondern nur darum faktisch falsche Aussagen zu zu wiederlegen. Ausdrücklich: Niemand sollte neue Anwendungen mit der BDE entwickeln. ... Das die BDE jedoch für C/S Anwendungen unbrauchbar gewesen sein soll oder für ein ernsthaftes Arbeiten zu buggy - das stimmt einfach nicht.

Ok. Beispiel aus unserem Bereich:

- Diverse Datentypen (nvarchar) aus MS-SQL werden nicht korrekt über ODBC und BDE übertragen (Spalten kommen Teilweise nicht an)
- Diverse Abfragen (komplexere Joins mit Prepared) Statements krachen bei verwendung über BDE. Gleiche Statements über ADO (früher mit ADOExpress/dbGo, jetzt ohne) funktionieren einwandfrei.
- Absturz BDE-Anwendung wenn viele "breite" Spalten in Ergebnisdatenmenge zurückkommt (evtl. irgendeine fest X-KByte-Pro Datensatz Grenze).

Unsere erste native DB-Zugriffskomponente war für Oracle da hier die BDE an allen möglichen Ende gekracht hat. Was genau es war kann ich nicht sagen da das vor meiner Zeit und vor der Einführung eines Bugtracking-Systes war.

Übrigens: Seit wir keine BDE mehr haben ist unser Support bezüglich Installation nötiger DB-Zugriffskomponenten nahe 0 gesunken.

[Jonas]

Zitat:

Zitat von exilant

Das die BDE jedoch für C/S Anwendungen unbrauchbar gewesen sein soll oder für ein ernsthaftes Arbeiten zu buggy - das stimmt einfach nicht.

Soll also heissen, dass wenn ich nun ein Programm auf basis von BDE habe ich es schon auf benutzen kann, aber eben das nächstes mal auf neuere Sachen setzen sollte?

Also wie schon gesagt, ich habe bisher nie Probleme damit gehabt. Von daher dachte ich eben es wäre schon 'ok' BDE zu nutzen.

Zitat:

Zitat von Bernhard Geyer

Bei der BDE müsstest du beim Zugriff auf MS Access die DAO-Komponenten mitliefern (ok, du kannst noch einen größeren Umweg über ODBC machen) welche du nur mitliefernt darfst wenn mindestens ein Programm mit einer MS-IDE erstellt wurde.

Hm? Die BDE ist doch kostenlos und enthält doch standartmäßig über ODBC die Treiber für den Zugriff auf MS Access? :?:

[Bernhard Geyer]

Zitat:

Zitat von Jonas

Soll also heissen, dass wenn ich nun ein Programm auf basis von BDE habe ich es schon auf benutzen kann, aber eben das nächstes mal auf neuere Sachen setzen sollte?

Du solltest m.E. auch deine schon entwickelten Sachen umstellen. Ich halte die BDE für eine Zeitbombe die mit jedem Windows-Update hoch gehen kann, sprich: Sie geht nicht mehr.

Zitat:

Zitat von Jonas

Hm? Die BDE ist doch kostenlos und enthält doch standartmäßig über ODBC die Treiber für den Zugriff auf MS Access? :?:

Was ist wohl fehleranfälliger:

Anwendung -> BDE -> ODBC -> ODBC-Jet-Treiber -> JET-Engine -> DB

oder

Anwendung -> ADO -> JET-Engine -> DB



Jede Zwischenschicht verringert die Performance und birgt Inkompatiblitäten.


Am besten ist natürlich

Anwendung -> Native Zugriffskomponenten -> DB

Aber für MS Access ist der Weg über ADO ok.

[mkinzler]

Zitat:

Soll also heissen, dass wenn ich nun ein Programm auf basis von BDE habe ich es schon auf benutzen kann, aber eben das nächstes mal auf neuere Sachen setzen sollte?

Wo gibt es den die rosa Brillen zu kaufen? :mrgreen:

Du scheinst die ganzen Schlaglöcher und Probleme überlesen zu haben. Imho ist die (Pferd) Bde nicht blos tot sondern ist unter dem Reiter schon fast verwest. Komischerweise hat er dies noch nicht bemerkt.

[MrSpock]

Zitat:

Zitat von mkinzler

Du scheinst die ganzen Schlaglöcher und Probleme überlesen zu haben. Imho ist die (Pferd) Bde nicht blos tot sondern ist unter dem Reiter schon fast verwest. Komischerweise hat er dies noch nicht bemerkt.

:lol:

Neue Anwendungen laufen bei mir nur noch auf Firebird mit FibPlus als Zugriffskomponenten, aber die Anwendungen, von denen ich ja schon einiges in anderen Threads erzählt habe, die laufen immer noch ohne Probleme mit BDE und Paradox (!). :shock: :mrgreen:

[mkinzler]

Noch.

[QuickAndDirty]

Hallo,
Ich schreibe gerade an einer TDataset komponente die als Fassade für eine per DLL oder BPL zur verfügunggestellten
Datenbank dienen soll. Ich kann nur sagen es ist viel arbeit, und wir nehmen die auf uns um die BDE loszuwerden ohne
die ganzen mit der oberfläche verbundenen TTable objekte der BDE Los zuwerden ohne Alle Formulare neue zu bauen, und
alle Ereignisse neu zu programmieren...

Die BDE kann zum beispiel folgende probleme machen

-Ab einer geweissen Datenmenge kann es sein das ein Range leer zurrück geliefert wird.
Wenn man aber einen z.b. Maxint wert datensatz und einen MinInt Datesatz in dem Index anlegt geht er wieder. Wieso?
Das ließe sich auch mit diesem DUtil beheben aber dann ist es irgendwann wieder drinn.

-die Datenbank ist in der Default Installation auf gaaanz kleine Rechner ausgelegt. man muss alle werte in der System.init ändern...

-Es kann passieren das die BLOB datei kaputt geht, man muss die dann Löschen!!!

-Wenn man eine MS-SQL-Tabelle über BDE öffnet hohlt der die gesammte Datenmenge!!!! und das obwohl mannoch garnicht gelesen hat...wir musten ein Dataset Schrieben was immer erst bei Einem Lesenden Oder schreibenden Zugriff die tätig wurde.

-Wenn du ein Query absetzt wird der Inhalt der Ergebnissmenge vollständig in einer Datei auf dem Rechner gecached...
was soll das?

-Es ist ein riesen Rechte gehampel, man muss per UNC-PFad auf Freigaben auf einem Server zugreifen und die Administratoren LÜGEN einen an wenn man sie fragt ob wirklich vollzugriff für Jeder eingerichtet wurde...man testet es und... schwups... kann keine Dateien anlegen. Dann heist es immer "moment". Und ich hasse das das die sich für ihre Lügen nicht mal entschuldigen und das ist immer bei jeder Firma ab einer gewissen Größe so gewesen.

-Virenscanner mögen die BDE nicht...im schlimmsten fall kommt es vor das ein Virenscanner am client jeden zugriff scannt und ausbremst und zusätzlich auch noch der am Server. Und es gibt admins die noch nie einen Ordner vom Scann ausgenommen haben...ein riesen mist.(Immer UNC-Pfad, Netzwerklaufwerk und lokalen Pfad vom Scann ausschließen)

-Wenn man vergessen hat im MS-SQL-Server "Autocreate Statistics" abzuschalten erzeugt der für nahezu jede jemals gestellte anfrage eine eigenen Schlüssel.... das ist schon sau dumm ....aber die BDE hat scheint irgendwie nur 12-16 Schlüssel pro Tabelle zu unterstützen...sie liefert dann aber nicht etwa einen Fehler...nein es scheint so zu sein als würden die ganzen Schlüssel in den Speicherbereich der anderen Tabellen ragen und diese liefern dan komische Ergebnisse.

-0x6BDE000 <- warum?

-Zur BDE gibt es den Quellcode nicht(das währe wohl auch peinlich geworden)

-Da die BDE File basiert ist, hat sie die selben Probleme wie Jet was das Betriebsystem angeht.
Windows stellt einfach von haus aus keine echten Multiuser Freigaben zur verfügung. Stichwort (Opportunistic Locking)
Es kann bei zunehmender anzahl von Usern also immer wahrscheinlicher zu einer Zerstörung der Datei kommen.

-Die BDE macht in Diensten keinen Spass da immer UNC-Pfade und Freigaben verwendet werden müssen.(Netzwerklaufwerke gibt es nicht ohne Desktop)


Ansonnsten muss ich sagen das auch wenn ich es hier zum Teil anders vernehme die BDE mit Paradox sau schnell ist, wenn der Virenscanner vorher eingestellt wurde...
Insbesondere der Range Zugriffe ist aber auch irgendwie logisch schließlich hängt kein lahmer SQL Parser dazwischen.

[exilant]

Zitat:

Zitat von Jonas

Soll also heissen, dass wenn ich nun ein Programm auf basis von BDE habe ich es schon auf benutzen kann, aber eben das nächstes mal auf neuere Sachen setzen sollte?

Ja. So ungefähr. Du solltest aber durchaus bemüht sein, die BDE auch in bestehenden Projekten zu ersetzen.
Für neue Projekte gilt wie alle anderen hier auch geschrieben haben: Finger weg von der BDE.