Warum nicht BDE?

[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.