dbExpress Transaktionsmanagement (und Firebird)

[RSE]

Hallo,

ich arbeite mich gerade neu in dbExpress unter Delphi XE ein. Dort habe ich in der Hilfe zu RollbackFreeAndNil gelesen:

Zitat:

Alle aktiven Transaktionen, die nach dieser Transaktion begonnen wurden, werden auch zurückgesetzt und freigegeben.

Das simuliert ja quasi verschachtelte Transaktionen (die äußere Transaktion kann nur glücken, wenn alle innenern Transaktionen glücken). Falls der Server aber tatsächlich verschachtelte Transaktionen nativ unterstützt, würde ich das ja bestimmt auch irgendwie mitbekommen - ist da nicht irgendwas doppelt gemoppelt?
Das es verschachtelte Transaktionen überhaupt gibt, war mir bisher gar nicht in den Sinn gekommen. Ich war immer der Meinung, dass zwei nacheinander gestartete Transaktionen vollkommen unabhängig voneinander sind.

1. Wie läuft das zwischen dbExpress und Firebird mit diesen "geschachtelten Transaktionen" tatsächlich?
2. Wie startet man mit dbExpress 2 unabhängige Transaktionen? Geht das nur über einzelne Verbindungen? Ist Firebird bzgl. der Verbindungen pro Client begrenzt?

Falls es zu den Fragen bereits Antworten gibt, die ich nicht gefunden habe, dann bitte ich um einen Link und bin sehr gerne bereit mir diesen zu Gemüte zu führen. Leider ergab meine vorher durchgeführte Suche allerdings keine brauchbaren Ergebnisse. Vielleicht benutze ich aus Unkenntnis nicht die richtigen Suchwörter.

OT: Was mich außerdem noch etwas stört an dbExpress ist das automatische Verbinden zum Server, wenn ich die Query öffne. Kann man das irgendwie abstellen? Ich hätte lieber einen auswertbaren Hinweis/Fehler wie bei TIBDatabase möglich. Oder bin ich mit den Anforderungen (Firebird + Verbindungs- und Transaktionsmanagement selbst in die Hand nehmen) mit den IB-Komponenten besser beraten?

[tsteinmaurer]

Ich hab mich mit dbExpress nie wirklich ernsthaft auseinandergesetzt, aber durch den unidirektionalen/disconnected Ansatz, wo man in die TClientDataSet Schiene kommt, um z.B. ein Grid anzubinden, ist doch etwas Umstellung notwendig, wenn man andere Zugriffskomponenten gewohnt ist. Wenn mich nicht alles täuscht, geht auch nur eine explizite Transaktion je Connection. Das alles sind keine konkreten Antworten, aber wenn dein Projekt etwas neues ist und du nur Firebird unterstützen musst, dann gehe in Richtung IBObjects, IBDAC, FIBPlus ... Wenn du Multi-DB Support benötigst, dann in Richtung AnyDAC oder UniDAC. Mit all diesen Produkten holt man einfach mehr raus.

[RSE]

Ja, das Projekt ist neu. Ja, Firebird ist vorerst das einzige DBMS, das unterstützt werden muss. Wir wollen allerdings von externen Komponenten Abstand nehmen und das Ganze mit Bordmitteln umsetzen. Damit bleiben wohl dbExpress und die Interbase-Komponenten, wenn ich das richtig überblicke. Die Interbase-Komponenten scheinen mir hier weniger "Hexerei" zu betreiben, di ich nicht haben will. Mit ClientDataSet habe ich mich bereits auseinandergesetzt und ich finde den Ansatz gut.

[mkinzler]

Zitat:

Ja, das Projekt ist neu. Ja, Firebird ist vorerst das einzige DBMS, das unterstützt werden muss. Wir wollen allerdings von externen Komponenten Abstand nehmen und das Ganze mit Bordmitteln umsetzen.

Gibt es hierfür einen Grund?

[RSE]

Zitat von mkinzler:

Zitat:

Ja, das Projekt ist neu. Ja, Firebird ist vorerst das einzige DBMS, das unterstützt werden muss. Wir wollen allerdings von externen Komponenten Abstand nehmen und das Ganze mit Bordmitteln umsetzen.

Gibt es hierfür einen Grund?

"Sparsamkeit" der Geschäftsleitung. Allerdings bin ich bei ersten Tests mit den IB-Kompos sehr gut zurechtgekommen. dbExpress hat zu diesem Thread geführt. Ihr könnt mir gern triftige Gründe aufführen, wenn ihr mich überzeugen könnt, könnte ich vielleicht noch was daran ändern, aber dann müssen triftige Gründe kommen.

Die Originalkomponenten haben in unseren Augen folgende Vorteile:

• Gut getestet
• Entwicklung/Unterstützung wird nicht unerwartet eingestellt werden (auf dbExpress sicher mehr zutreffend als auf die IB-Kompos?)
• Keine zusätzlichen Kosten

Die gleichen Gründe sprechen gegen Fremdkomponenten. Die IBOs hatten wir z.B. bisher im Einsatz, sind uns aber zu teuer.

[mkinzler]

Für dbExpress bräuchtest du aber dann auch die Enterprise von Delphi oder einen 3rd-Party/Freeware dbExpress-Treiber.

[p80286]

[OT]
Das mit der Sparsamkeit kenn ich ganz gut, daher bin ich von BDE über ODBC bei ADO gelandet.
Das ging alles mit Bordmitteln und war (meistens) ausreichend performant. Jetzt ist ADO out und ODBC wieder in, und morgen?
Irgendwann muß man das Risiko eingehen und sich entscheiden, die Frage ist immer nur wie lange es gut geht.
[/OT]

Gruß
K-H

[RSE]

Dann haben wir offenbar die Enterprise, denn ich habe schon über dbExpress mit dem DB-Server kommuniziert und mir Tabellenwerte ausgeben lassen. Daher meine Beobachtungen aus dem ersten Beitrag.

[tsteinmaurer]

Die IBX-Komponenten würde ich mit Firebird nicht verwenden, da diese offiziell Firebird nicht unterstützen. Borland/Codegear/EMB hat das oftmals klargestellt. Auch wenn sie vielleicht noch funktionieren, heißt es nicht, dass dies auch in Zukunft der Fall sein wird, also aus meiner Sicht eine Sackgasse.

Einmalige/jährliche Lizenzkosten für Third-Party ist ja nur eine Seite, wenn man von Kosten spricht. Kann mir gut vorstellen, dass das Einarbeiten in eine neue Zugriffstechnologie bei weitem die Lizenzkosten für ein bereits vertrautes Toolset übersteigen. Ich weiss, das wollen die Leute nicht hören, weil Personalkosten fix kalkuliert und budgetiert sind und es nichts ausmacht, wenn man da z.B. 1 Woche in der Einarbeitung drinnen hängt.

Alles Gute für das weitere Vorgehen.

[RSE]

tsteinmaurer: Vielen Dank für diese Informationen. Es erstaunt mich zwar, dass ein extra Firebird-Treiber mitgeliefert wird und dann gesagt wird, dass dieser nicht unterstützt wird, aber wenn dem so ist, nehme ich das hin.

Wie sieht es mit den Interbase-Komponenten im Zusammenspiel mit Firebird aus?