dbExpress Transaktionsmanagement (und Firebird)

[TRomano]

Moin, Moin !

"Deine" Geschäftsleitung sollte sich wirklich für externe Komponenten entscheiden, denn wie immer kommt in einem größeren Projekt der Punkt, wo es mit den Bordmitteln hakt oder gar nicht mehr weitergeht bzw. der Aufwand exponential steigt. Vielleicht sollten sie einfach mal ausrechnen, wieviel Mannstunden dem Preis einer externe Komponente wie UniDAC entsprechen (je nach Stundensatz meist weniger als ein Manntag). Was wirklich schwerer fassbar ist die spätere Zeit- (und damit Kosten-) Ersparnis der externen Komponenten zu "messen". Aber nach über 20 Jahren Codier-Erfahrung kann ich nur sagen, dass Komponenten wie "DevExpress", "UniDAC" (nur zwei beispiele) in den größeren Projekten jeden Cent wert waren.

MfG

[RSE]

Nochmals: Was genau sparen mir diese gekauften Komponenten? Jeder sagt sie sparen, aber keiner sagt was sie genau sparen und unter welchen Umständen sie das tun. Ich möchte z.B. keine DB-sensitiven Elemente mehr verwenden. Momentan gehe ich davon aus, dass sich die Ersparnisse darauf beziehen.

Bitte, wenn ihr mir externe Komponenten vorschlagt, dann sagt dazu was ich damit an Entwicklungsaufwand sparen kann und nicht nur das es so ist! Wie soll ich denn bitte sonst abschätzen, ob diese Ersparnisse für mich überhaupt zutreffen?

p.s.: Bitte entschuldigt, wenn ich immer über mich statt uns schreibe. Wir sind ein Über-100-Mann-Unternehmen mit mehreren Delphi-Programmierern.

[tsteinmaurer]

Aus dem Bauch raus ...

dbExpress ist ein Multi-DB-Framework und erlaubt dir theoretisch durch Änderung des Connect-String, ein und die selbe Anwendung auf mehrere DBMS-Produkte zu verbinden. Dass das Ganze nur ein kleines Puzzle-Teil bei einer Multi-DB-fähigen Anwendung ist, zeigt die Praxis. dbExpress bietet dir keine Unterstützung für Firebird-spezifische Dinge wie Unterstützung für die asynchronen Firebird Events in deiner Client-Anwendung, Two-Phase Commit, Services API und ich habe jetzt auch keinen Hinweis gefunden, dass mehrere gleichzeitigen Transaktionen je dbExpress-Connection gehen.

Ich kann jetzt nur verstärkt über IBObjects sprechen, aber da hast du dann halt Mechanismen im Hintergrund um OIT/OAT, wenn möglich, automatisch nachzuziehen, DML Caching zur automatischen Benachrichtigung der Table/Query-Komponenten bei Datenänderungen, auch über Prozessgrenzen hinweg, soviele Transaktionen je Connection-Objekt wie du willst und VIELES MEHR.

Nicht zu verachten ist auch der Lizenz-Kostenfaktor, wenn du mit Delphi-Boardmitteln dbExpress mit Firebird einsetzen willst. Da brauchst nämlich die Enterprise Edition, was in der Regel teurer kommt als Delphi Professional + Third-Party native Komponenten. Ich hab auch so meine Bedenken wie fit Embarcadero in Bezug auf dbExpress-Treiberupdate für Bugfixing, Support neuer Firebird Versionen ist. Die Third-Party Hersteller sind da ziemlich fit.

* Ist das ein neues Projekt?
* Welcher Projektumfang in Bezug auf DB-Tabellenanzahl, Formulare, Datenmodule etc. kann man sich hier vorstellen?
* Müßt ihr neben Firebird auch noch andere DBMS-Produkte unterstützen?

[RSE]

Vielen Dank tsteinmaurer, das sind für mich Argumente!

• Es ist ein neues Projekt.
• Das Programm muss ständig um neue Projekte, die damit umgesetzt werden, erweitert werden, jedesmal kommen neue Tabellen hinzu. Die 2GB-Grenze von Interbase war für uns nicht in weiter Ferne, wobei pro Tabelle nur bis maximal 30.000 Datensätze üblich sind, oft nur ein paar hundert.
• Das Programm läuft ausschließlich hausintern und wir haben uns für einen Umstieg auf Firebird entschieden. Momentan muss also nur Firebird unterstützt werden. Das wird auch wieder lange so bleiben - Interbase 6.1 lief auch bis jetzt.
• Delphi XE Enterprise ist vorhanden. Damals wurde sich wegen der DB-Kompos für Enterprise entschieden, bevor man sich intensiv mit deren Möglichkeiten auseinandergesetzt hatte...

Ich habe seit gestern 1 Woche Urlaub, danach (ab Dienstag) werde ich mich intensiv mit den Möglichkeiten von (externen) DB-Komponenten auseinandersetzen.