Hi Hansa,
um Deine Frage zu beantworten "macht das jemand so in der Richtung?": ich mache das so, bei einem etwas zurückliegenden Projekt sogar ausschließlich. Auf Transaktionen muss ich ja hier nicht mehr eingehen, die wurden ausführlich behandelt. Allerdings nur schnell mal commiten reicht bei Interbase/Firebird auch nicht ganz, wenn Du mit datensensitiven Kompos wie DBGrid o.ä. arbeitest - die sind dann nämlich augenblicklich leergefegt, da Commit sämtliche über die Transaktion laufenden Datasets etc. schließt. Man müsste also sämtliche offen gewesenen Datenmenge neu öffnen (in Mehrbenutzerumgebungen teilweise kein Manko, da erwünscht).
Meine Lösung war tatsächlich der Einsatz zweier Transaktionen mit folgenden Aufgaben:
- Transaktion 1 zum Lesen, solange ein Fenster, bzw. die Datensicht offen ist. Das automatische Schreiben der benutzten datensensitiven Komponenten wird abgefangen und unterbunden, stattdessen wird ein SQL String erzeugt und an die
Transaktion 2 zum Schreiben (Insert, Update) geschickt.
Großer Vorteil hierbei: Das Schreiben lasse ich eben nicht DBGrid, bzw. DBEdit machen, sondern verwende ausschließlich
SQL über die entsprechende Komponente, die über Transaktion 2 läuft, was schneller nicht geht. Diese Transaktion "lebt" tatsächlich nur für die Dauer des Schreibens. Nach dem Schreiben lese ich die über Transaktion 1 offenen Datasets neu ein, damit die Änderungen auch sichtbar werden. Vor diesem Requery werden sämtliche Datenanzeigen mit Dataset.DisableControls eingefroren, um Flickern zu verhindern, abschließend werden die Anzeigen mit Dataset.EnableControls wieder freigegeben.
Gruß harrybo