Datenbank: any • Version: any • Zugriff über: BDE
Warum BDE nicht (mehr) benutzt werden sollte
BDE wird schon lange nicht mehr weiterentwickelt.
Die Stabilität ab Windows 7 ist nicht so gut. Ich bitte um weitere Beiträge. |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Du nennst doch die Gründe schon selbst.
Ein wenig trauere ich der BDE schon nach. Die Lernkurve und der Installationsaufwand waren gering. Aber für ernsthafte und größere Projekte war die BDE noch nie (jedenfalls schon viele Jahre nicht mehr) optimal. |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
|
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
Also sind wohl Links zu mehr oder weniger belastbaren Quellen mit offiziellen Aussagen, Erfahrungsberichten, Erfolge durch Umstellung, Benchmarks, usw. gefragt. |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
Aber warum nicht nehmen: - Hoher Konfigurationsaufwand: BDE installieren (wird nicht überall erlaubt sein), BDE und ODBC-Quellen einrichten. Evtl. wissen aufbauen wie man welche Einstellungen vornehmen muss damit es überhaupt funktioniert: - Lizenzprobleme. Bei MySQL fällt man in die GPL-Falle. - Keine 64-Portierbarkeit. Oder hat schon jemand eine 64-Bit BDE gesehen? - Ansprechen von neuen DB-Features. Diverse neue DB-Features/Datentypen lassen sich nur schwer oder gar nicht ansprechen - Unicode-Kompatiblität. Oder kennt jemand eine Unicodefähiges dBase/Paradox das direkt mit der BDE zusammenarbeitet? - Hoher Supportaufwand. All die BDE/ODBC-Einstellungen sind nunmal schwerer stabil zu bekommen als wenn man mit einer nativen Zugriffskomponente nur Ziel-DB, Ziel-Server und Username/PW mitgeben muss damit es geht. |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
Und wehe es kommt eine zweite BDE-Datenbank auf den Rechner,... Danach bin ich auf ODBC und ADO umgestiegen. Da kann ich die funktionierende Konfiguration aus mehreren Treibern zusammen setzen. Gruß K-H |
AW: Warum BDE nicht (mehr) benutzt werden sollte
64bit-BDE (zumindest eine funktionierende) gibt es. Hatten wir schon mal in der DP.
Nicht, dass ich das empfehlen will, aber für Notfälle... |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
Und Lernaufwand? OK, um "Spiel-Datenbanken" zu betreiben ok. Wenns ans eingemachte ging war die BDE eher hinderlich. |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
|
AW: Warum BDE nicht (mehr) benutzt werden sollte
Ja, ich meinte "lauffähig".
|
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
Wie siehts mit Win8 (nicht RT) aus? Ist hier jetzt die BDE entgültig gestorben oder wirken die Tricks noch? Würde mich freuen wenn's nicht mehr gehen würde. |
AW: Warum BDE nicht (mehr) benutzt werden sollte
-permanent defekte Blobfelder
-ein richtiger Hänger in der BDE ist nur durch reboot zu beheben -so gut wie keine SQL - Fähigkeiten -bei Indexfehlern dreht sich der "Cursor"im Kreis, "while not EOF's" laufen in Endlosloops -was man sucht: Feldtypen, Unicodefähig, echte Netzwerkfähigkeit, Trigger, Prozeduren, Views, Rechteverwaltung ... sicher beliebig erweiterbar ... |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Hallo,
Einfach mal nach Index Out of Date Blob file has been modified suchen. Wobei das Problem bei Paradox liegt, nicht bei DBase. Vieles gibt es bei Paradox, naja immerhin :) Heko |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Man kann die Frage mit
"Warum Faustkeile nicht mehr benutzt werden sollten", oder "Wieso sind Handkarren im Stadtverkehr suboptimal" übersetzen. Zumindest mir wird dann intuitiv klar, das die Frage sich selbst beantwortet. Argumente sind natürlich besser, aber es wurden schon alle genannt und manchmal ist eine Metapher auch verständlich. |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
Nicht mehr immer funktionieren tut der Zugriff auf z.B. Netzwerkfreigaben von verschiedenen Programmen auf die selbe Datenbank. Das lief noch nie ganz reibungslos, aber mit den neuen Windowsversionen gibt es immer mehr Probleme. Wenn man SMB 2.0 abschaltet, läuft es aber auch noch unter Windows 7 und 8 einigermaßen gut mit DBase. Für neue Projekte macht die BDE natürlich überhaupt keinen Sinn, da sie seit einem Jahrzehnt tot ist und nicht mehr weiterentwickelt wird. Und bei älteren Projekten ist ebenfalls genau das ein Problem, da keine Lösungen und Bugfixes mehr für Probleme kommen werden. |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Ich habe gerade wieder eine seit Jahren ohne Probleme laufende BDE Anwendung auf Firebird umgestellt. War ziemlich aufwendig. Ich kann aber nicht bestätigen, dass die Anwendung unter Win 7 irgendwelche Probleme hatte. Ich wollte sie nur zukunftsfähig machen, weil ich erwarte, dass es zukünftig mit der BDE Probleme geben wird. Mit der BDE habe ich aber weder auf einem 32-bit Win 7 noch auf einem 64-bit Win 7 Probleme gehabt.
|
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
|
AW: Warum BDE nicht (mehr) benutzt werden sollte
Hallo,
ich habe meine Applikation auch von BDE auf ADO und MS-SQL umgestellt. Aber: Zitat:
Ciao Frank |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
Für Neuprojekte gilt natürlich, dass man auch mal über etwas anderes nachdenken darf. Ich habe bisher auch keine Probleme mit der BDE gehabt für die Altprojekte. Für WIN8 kann ich da aber noch nicht sprechen. |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
|
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
|
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
|
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
|
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
Was nervt ist, dass bei jedem BDE-Thema einer der ersten Antworten immer ein BDE-Bashing ist. Ich denke einige hier verdienen mit coden ihren Unterhalt und es ist nicht immer möglich 1000e Zeilen Code zu durchforsten, BDE abzulösen, ggf. DB-Anpassungen durchzuführen und das alles noch zu testen. Vor allem wenn der Endanwender dir das nicht bezahlt, da er in erster Linie keinen Nutzen hat. Jeder muss selber abwiegen ob der Aufwand einer Ablösung ihm Wert ist. |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
Ok, wir freuen uns das wir des öfteren neue Kunden bekommen bei dem der bisherige SW-Lieferant die Schiene "Never Change a running system" fährt bzw. für solche Umstellungen Geld will. |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Die Abkündigung der BDE kam mit D7 ( 2002), die aktuelle Delphiversion ist D17 ( eigentlich D16, da es kein D13 gab). Das ist nun 10 Jahre her. Und ich bin mir sicher, dass der Aufwand an der Software um diese auf eine andere Technik umzustellen geringer gewesen wäre, als die ganzen Klimmzüge, die nötig waren, die BDE-Programme auf neuen OS-Versionen lauffähig zuz machen. Beim Zugriff auf externe DBMS war die BDE zudem schon immer ein Hemmschuh!
|
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
Ich habe aktuell einen Kunden an der Backe (Delphi 5 + QR + BDE). Dem sind die Probleme durchaus bewusst. Und jetzt kommst Du her und behauptest, dass ich als Freiberufler mal eben so 60-80h in die Umstellung auf System X durchführen soll -. ohne Berechnung?!?!? Habe ich irgend was in der gesellschaftlichen Entwicklung verpasst? Bedingungsloses Grundeinkommen vielleicht? ;-) Warum soll ich meinem Kunden eine Verbesserung ohne Gegenleistung implementieren? Er hat von der Umstellung ein deutlich leistungsfähigeres System, kann neue Kunden fischen (Netzwerkfähigkeit) und die Peformance und Stabilität erhöht sich (ich sag nur Indexfehler). Bitte um Aufklärung! Grüße |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
Zitat:
Zitat:
|
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
Zitat:
...die Diskussion kann so unendlich fortgeführt werden..bringt ja nichts. Sollte nun ein Kunde sich technisch neu orientieren und das böse BDE-Programm läuft nicht mehr mit dem System, dann wird er auch ohne jede Anstrengung bereit sein wieder mehr Geld zu investieren. ich habe jedenfalls die Kunden die es betrifft diesbezüglich aufgeklärt. |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
Zitat:
Zitat:
|
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
Zitat:
Zitat:
|
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
Zitat:
Ich denke es kommt hier einfach auf die Umstände drauf an: Uraltprojekte, die halt gepflegt werden, wo aber sichtbar ist, dass Kunden wie auch der Eigentümer (bitte nicht falsch verstehen) absehbar "aussterben" (Geschäftsaufgabe, Rente,...) - weshalb soll man sich da eine solche grundlegenede Architekturänderung durchführen? Dass der Zeitpunkt schon vor 5-7 Jahren verpasst wurde, kein Thema, da brauchen wir auch nicht drüber reden. Wenn es um Einstieg in die DB Entwicklung geht, um Prototypen oder um kleine Hilfstools - da gibts zig bessere Alternativen die einem auch in Zukunft noch weiter helfen können. |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
Im Radio wurde hier und hier zum gestrigen Münchner Stromausfall erläutert, die Steuerungssoftware wäre schon so alt, dass kaum noch jemand das System komplett verstehen kann. Ein anderes Motto und ein Rezept gegen Softwareverfall, das man in der IT Praxis oft hört. ist die Pfadfinderdevise (Boy Scout Rule): einen Platz immer in besserem Zustand zu verlassen als man vorgefunden hat. |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
Zitat:
Oder wie würde es Steuerlich mit der Kosten aussehen wenn es nicht die Olttimer-Regelung gäbe? |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
Zitat:
Zitat:
|
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
|
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
Zitat:
GRüße |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
Zitat:
Meines Erachtens ist z.b. Pascal in den frühen 70er erschienen und wir programmieren heute immer noch damit, obwohl es auch neuere Sprachen gibt. Wenn wir jedes mal auf neue Sprachen, Techniken usw. switchen würden, das könnte doch kein Mensch bezahlen, nur weil es immer das neueste, modernste oder beste ist. |
AW: Warum BDE nicht (mehr) benutzt werden sollte
Zitat:
|
AW: Warum BDE nicht (mehr) benutzt werden sollte
Hi,
Zitat:
Ciao Frank |
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:05 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz