FIBPlus Transaktions-Problem

[spechto]

Hallo zusammen,

ich bastele gerade an einer kleinen Anwendung, in der ich ein Fenster mit einem DBGrid habe. Das DBGrid bezieht die Daten aus einem FIBDataset (ReadTransaction, read-only). Nun soll bei einem Doppelklick auf eine Zeile ein Detail-Fenster aufgehen, in dem die Daten bearbeitet werden können. Also übergebe ich dem Detail-Formular die FIBDataset-Komponente in einem Property und nutzte für die Transaktion die WriteTransaction des FIBDataset. So funktioniert das Ganze auch wunderbar.

Nun möchte ich, dass mehrere Instanzen vom Detail-Fenster möglich sind. Leider bekomme ich nun Probleme hinsichtlich des Transaktionskontexts. Wenn im Detail-Fenster die Transaktion gestartet wird und beim Schliessen des Fensters beendet wird, gibt es natürlich Probleme beim Schliessen der nächsten Instanz, da die Transaktion ja bereits beendet wurde.

Wie kann ich dieses Problem am besten (oder besser am saubersten) umgehen? Eine Idee wäre es, zu prüfen, ob die Transaktion bereits läuft und statt eines Hard-Commit einfach CommitRetaining zu nutzen. Das Hard-Commit müsste dann von der ersten Formular-Instanz ausgeführt werden.
Ist das die richtige Richtung, in die ich da Denke oder liege ich mal wieder voll daneben?
Die Write-Transaction wird dadurch natürlich unter Umständen recht lang ...

Vielen Dank
Martin

[mkinzler]

Zitat:

Nun möchte ich, dass mehrere Instanzen vom Detail-Fenster möglich sind.

Ist das wirklich nötig.
Detailfenster und Transaktionskontext dynamsich erzeugen

[spechto]

Mehrere Instanzen des Detailfensters wären schon sehr schön und würden ein flexibleres Arbeiten ermöglichen. Der Transaktionskontext wird ja von der FIBPlus-Dataset-Komponente mehr oder weniger festgelegt: Eine Read und eine Write-Transaction. Da ich ja dieses Dataset in dem Übersichtsform mit dem DBGrid definiert habe, übergebe ich dieses ja als Property (als Zeiger) an jede Detail-Instanz. Der Ansatz mit dem CommitRetaining würde also nur dann funktionieren, wenn jedes Form kontolliert, ob es das letzte seiner Art ist ...

Ich könnte auch eine eigene Transaktion im Detail-Formular definieren, so dass mit jeder neuen Formular-Instanz eine eigene Transaktion erzeugt wird. Das Problem, welches ich allerdings hierbei erwarte (da schonmal aufgetreten, wenn ich mich recht erinnere), ist das, dass das DBGrid-Form sich nicht automatisch aktualisiert, also die Änderungen der Detail-Forms nicht anzeigt ...

Wäre schön dafür eine Lösung zu finden ... Besten Dank ...

[hoika]

Hallo,

deine Lösung mit "pro Form eine Transaktion" würde ich auch nehmen.
Natürlich muss nach dem Detail-Commit die Master-Transaktion neu gestartet werden,
(DataSet.Close, Commit, StartTrans, DataSet.Open)


Heiko

[spechto]

Zitat von hoika:

Hallo,
Natürlich muss nach dem Detail-Commit die Master-Transaktion neu gestartet werden,
Heiko

Hallo Heiko,

danke für Deinen Tipp. Der Vorteil bei dieser Variante wäre, dass auch Änderungen anderer CLients sofort sichtbar wären. Ein großer Nachteil wäre aber der Performanceverlust bei langsamen Leitungen zur DB (z.B. DSL VPN-Verbindung). Von daher wäre mir eine Lösung, die die Funktionalität der FIBPlus-Dataset-Kompo nutzt lieber ... was spricht (vom Aufwand mal abgesehen) dagegen? Oder kann man das Performance-Problem anders in den Griff bekommen?

Die andere Frage ist natürlich, ob es überhaupt sinnvoll ist via CommitRetaining über mehrere Detailinstanzen zu arbeiten, oder ob hier die Gefahr besteht, einen Datenverlust zu erleiden, wenn das Hard-Commit aufgrund eines Verbindungsabbruchs (oder Softwarefehler) nicht erfolgt ...

Grüße
Martin

[hoika]

Hallo,

definiere Performanceverlust bei langsamen Leitungen zur DB (z.B. DSL VPN-Verbindung).
Warum soll es dazu kommen ?
Hast du es mal probiert ?

Wenn du natürlich in deinem DBGrid eine grosse Tabelle komplett offen hast (select *),
bist du selber schuld, böse gesagt.

Du kannst das TIL der Main-Trans auf read commited setzen,
dann müsste sollte es schneller gehen.

Ein commit retaining der Detail-Trans macht aber keinen Sinn,
da das Detail-Form doch eh geschlossen wird.
Ausnahme:
Du willst die Original Main-Transaction benutzen.
Davon rate ich ab.


Heiko

[spechto]

Zitat von hoika:

definiere Performanceverlust bei langsamen Leitungen zur DB (z.B. DSL VPN-Verbindung).

Bei einer VPN-Verbindung benötigt das Programm circa 9 Sekunden zum Lesen von 80 Datensätzen,
allerdings nur bei der ersten Abfrage. Liegt die Datenbank lokal auf dem Rechner, wird für die
gleiche Aktion weniger als eine Sekunde benötigt. Interessant dabei ist allerdings, dass bei
Verwendung der VPN-Verbindung ein Schließen und erneutes Öffnen der Datenmenge auch
weniger als eine Sekunde benötigt.

Zitat von hoika:

Du kannst das TIL der Main-Trans auf read commited setzen,
dann müsste sollte es schneller gehen.

Habe ich gemacht, ist aber bei den den wenigen Datensätzen nicht spürbar.

Zitat von hoika:

Ein commit retaining der Detail-Trans macht aber keinen Sinn,
da das Detail-Form doch eh geschlossen wird.
Ausnahme:
Du willst die Original Main-Transaction benutzen.
Davon rate ich ab.

Ich wollte die UpdateTransaction der FIBDataset-Komponente aus dem DBGrid nutzten, zum einen,
weil ich mir dann einen erneuten Select Befehl sparen kann und auch beim Schließen des Formulars
die Datenbankverbindung nicht neu initiieren muss. Das Ganze funktioniert auch bei einem
modalen DetailForm hervorragend. Nur bei mehreren Instanzen kommt das CommitRetaining ins
Spiel und das wiederum finde ich auch nicht so schön.

Martin

[hoika]

Hallo,

9 Sekunden ist viel.

Zitat:

allerdings nur bei der ersten Abfrage

Kann es sein, dass da das Connect zur DB
noch mit gerechnet ist ?


Heiko

[spechto]

Zitat von hoika:

Hallo,
Kann es sein, dass da das Connect zur DB
noch mit gerechnet ist ?

Hallo Heiko,

denke ich nicht, da die DB zwecks Passwort-Abfrage bereits schon im Vorfeld konnektiert wird.
Wie gesagt, die 9 Sekunden braucht das Programm nur bei einer DSL-VPN-Verbindung (ca. 1 MBit).

Martin