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:

Zitat von mkinzler (Beitrag 1172718)

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. :thumb:

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

[mkinzler]

Zitat:

Zitat von RSE (Beitrag 1172736)

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?

Du hast Thomas gerade falsch herum verstanden. Für dbExpress gibt es einen speziellen FireBird Treiber, aber Interbase Express (IBX) ist für Interbase optimiert.

[RSE]

Stimmt, ich hatte DBX statt IBX gelesen... Danke für die Klarstellung!

Damit wird wohl dbExpress mit dem Firebird-Treiber zum Einsatz kommen. Jetzt sind wir brandaktuell beim ersten Beitrag angekommen, der den Thread hier eröffnet! Zu den dort gestellten Fragen hat noch keiner was gesagt. Nichtsdestotrotz (wie es auch immer zu schreiben ist) sind auch alle anderen Infos sehr hilfreich gewesen und ich bedanke mich dafür.

[tsteinmaurer]

Ich meinte bei meiner Aussage die IBX-Komponenten und nicht den Firebird dbExpress-Treiber, der mit der Enterprise Version mitkommt.

[Furtbichler]

Zitat:

Zitat von RSE (Beitrag 1172719)

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

Es ist natürlich wichtig, kostenoptimiert zu arbeiten. Gerade deshalb lohnt der Einsatz von professionellen Third Party Components.

Die Zeit, die ihr für das Entwickeln mit 'Bordmitteln' benötigt, bzw. bei der Erweiterung, wenn doch mal ein zweites RDBMS hinzukommt, kostet Geld.

Die Evaluation und der Kauf einer guten Komponente kostet auch Geld.

Preisfrage: Was ist teurer?

Wir haben z.B. DevExpress (Visualisierung, Eingabe, Grids etc.), FastReport(Reporting) und TSiLang (Lokalisierung, Multilanguage) eingekauft, einfach weil wir Front-End Anwendungen mit Datenanzeige, -Eingabe, Reporting für Kunden im In- und Ausland entwickeln.

Wir konzentrieren uns auf die Kernproblematik, weil wir für das notwendige Gerüst (Grids, Reports, Sprachumstellung) bereits fertige Lösungen haben.

Die Entwicklungskosten für o.g. Produkte bzw. die für uns relevante Funktionalität beträgt grob geschätzt 5-10 Mannjahre. Ausgegeben haben wir nur einen Bruchteil => Gute Investition.

Ich würde übrigens eher Fremdkomponenten kaufen (sofern sie nicht zu teuer sind), als Dinge von vorne herein selbst zu entwickeln. Ich hab die Zeit dafür einfach nicht. Wenn man als GF entscheidet, alles selbst zu machen, hat man schlichtweg zu viel Geld.

[RSE]

Es ist ja toll, dass ihr mir hier Komponenten vorschlagt, die ihr gut findet. Sicherlich gehört zu der Einschätzung, was "gut" oder gar "besser" ist sehr viel Wissen über weitere Faktoren als der persönliche Geschmack. Ich habe bisher nur zu einem winzigen Bruchteil dieser Faktoren hier geschreiben. Wahrscheinlich kenne ich viele dieser Faktoren auch gar nicht. Wenn ihr also Komponenten vorschlagt, dann macht das in meinen Augen wenig Sinn, wenn ihr nicht dazuschreibt, von was für Voraussetzungen ihr ausgeht. Ich glaube nicht, dass es völlig unabhängig vom Einsatzzweck möglich ist eine Fremdkomponente als "besser" als die mitgelieferten zu einzustufen.

Ergo: Wenn ihr mir hier Komponenten vorschlagt, dann sagt bitte dazu, unter welchen Voraussetzungen diese Kompos besser sind und in was sie besser sind. Ansonsten hat die Info für mich keine Aussage.

Unabhängig davon befinde ich mich nicht in der Position die Geschäftsleitung über Investitionsentscheidungen belehren zu können. Außerdem sind unsere Anforderungen so kurzlebig, dass wir ständig am umprogrammieren sind (ständig wechselnde Inhalte des Programms, die von ständig wechselnden Auftraggebern vorgegeben werden). Eine Ausrichtung auf bestimmte Anzeigeelemente ist also nicht zielführend. Bezüglich der reinen Kommunikation mit der DB unterscheiden sich die Bordmittel sicherlich nicht wesentlich von Fremdkompos. Wenn ich mich für Fremdkomponenten entscheiden müsste, damit sich das Programm nicht automatisch mit dem Server verbindet, sondern erst wenn ich es ausdrücklich sage (und zwar der Verbindungskomponente und nicht irgendeiner Query/Dataset), dann könnte ich der Geschäftsleitung niemals eine wesentliche Investition dafür abverlangen und alle Risiken von Fremdkomponenten dafür eingehen. Die Kosten und Risiken würde ich selbst nicht investieren für diese eine Anforderung. Ich denke nicht, dass die vielen Mannjahre, von denen hier geredet wird, auf diesem Level investiert/gespart werden, sondern dass die Vorteile von Fremdkompos auf ganz anderem Gebiet liegen, das für uns nicht relevant ist. Uns geht es an dieser Stelle um die reine Kommunikation mit dem DB-Server.

Ich möchte auch nochmals darauf hinweisen, dass ich diesen Thread nicht wegen der Suche nach Alternativkomponenten eröffnet habe, sondern um eine Problemstellung mit den mitgelieferten dbExpress-Kompos zu lösen (siehe erster Post).

[RSE]

Arbeitet keiner mit dbExpess, oder hat noch niemand versucht zu verhindern, dass sich die Verbindungskomponente automatisch verbindet, wenn man eine Query startet? Beides würde mich wundern...

Falls euch mein letzter Post vor den Kopf gestoßen haben sollte: Das war nicht meine Absicht. Ich halte nur nichts von Pauschalaussagen. Viele Posts lasen sich wie "Dell ist toll". Ob Dell toll ist, kommt aber sehr auf die Anforderungen an. Für Unternehmen ist es toll, weil das Zusammenspiel aller Komponenten ausgiebig getestet ist und ein für Unternehmen wichtiger Support gegeben ist. Für Bastler ist Dell allerdings ganz und gar nicht das richtige, weil Dell an vielen Stellen eigene Standards hat (z.B. Formfaktor von Mainboards), so das ein Mix mit anderen Herstellern schnell problematisch wird. Man kann die Aussage "Dell ist toll" also nicht pauschalisieren. Gleiches gilt mit Sicherheit für DB-Zugriffskompos von Drittanbietern - eine Wertung dieser Kompos macht nur incl. Nennung der zugrundeliegenden Anforderungen Sinn.

Bitte sagt mir, wenn diese Auffassung falsch ist oder ich euch durch meine Aussagen verärgert haben sollte und nennt mir den Grund, damit ich euch das nächste Mal nicht wieder verärgere.

[omata]

Zitat:

Zitat von RSE (Beitrag 1173107)

Arbeitet keiner mit dbExpess, oder hat noch niemand versucht zu verhindern, dass sich die Verbindungskomponente automatisch verbindet, wenn man eine Query startet?

Ja und Nein.

Klar dbExpress ist eine wunderbare Sache und funktioniert sehr gut und schnell. Meine Anwendungen stellen beim Programmstart die Datenverbindung zur Datenbank her und diese Verbindung bleibt über die gesamte Laufzeit der Anwendung bestehen. Deshalb merke ich nichts davon, dass eine Query die Verbindung öffnet, sie ist offen.

[RSE]

Danke für die Antwort Omata. Ist bei uns ähnlich. Wenn aber ein Fehler wegen fehlender Verbindung auftritt statt sie automatisch zu öffnen, dann ist das leichter zu erkennen, falls doch mal jemand eine noch frühere Abfrage einbaut. Dann muss ich eben alternativ vorgehen und sicherstellen, dass vorher keine sinnvollen Infos drinstehen.

Bleibt noch die Frage zu den Transaktionen. Dazu wurden lediglich in der ersten Antwort Vermutungen angestellt. Ich bin leider auch seitdem nicht zum Testen gekommen.

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

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.