Transaktionen abschalten

[Mathias Berg]

Hallo,

ich bin gerade dabei eine Delphi 5-Anwendung mit Datenzugriff auf Paradox zu Interbase 6.01 umzusiedeln. Zugriff auf die DB erfolgt voraussichtlich ausschließlich über TIBQuery-Instanzen, die - falls erforderlich - alle gemeinsam eine(!) Transaktionskomponente verwenden sollen.

Ich möchte die ganzen implementierten SQL-Statements nicht ändern und damit auch keine commits einfügen. Auch ansonsten brauche ich die Transaktionsverwaltung nicht. Wie schaffe ich es, das die Datenänderungen direkt in der Interbase-db durchgeführt werden, sobald die Methode execsql der jeweiligen TIBQuery-Instanz aufgerufen wird? Kann man das zentral am IB-Server konfigurieren (z. b. set transaction = false :-)) oder muss das an der transaction-Instanz konfiguriert werden?

Vielen Dank für eure Statements (Rat/Kritik) im voraus.

Gruß

Mathias

P. S.: Frohe Ostern :-)

[Torsten Grundke]

Hallo Mathias,

bei den IBX-Komponenten muß Du dich selbst um die Transaktionssteuerung kümmern.

Wenn Du die Transaktionssteuerung umgehen willst (und dabei auf die Vorteile der eigenen Transaktionssteuerung verzichtest) muß Du eine eigene Komponente von TIBQuery ableiten und die Methode ExecSQL überschreiben. Statt IBQuery würde ich aber IBSQL verwenden.

Eine Kurzversion könnte so aussehen:

<pre>
<b>
begin
if not(Transaction.InTransaction) then
Transaction.Starttransaction;
inherited;
Transaction.commit;
end;
</pre>
</b>

Datensensitive Komponenten wie z. B. DBGrid können dann aber nicht mehr verwendet werden (weil eine offene Transaction dafür benötigt wird).

Tschüß

Torsten

PS: Persönlich arbeite mit den IBO-Komponenten und da muß man sich nur dann um die Transactionen selbst kümmern wenn das Anwendungsdesign es verlangt.

[Mathias Berg]

Hi Thorsten,

You got it! Thanks! Den Ansatz finde ich genial :-)

Die Konsequenz, dass keine datengebundene Steuerelemente verwendet werden können, ist ok (ich frage mich nur warum?!). Ich denke mal die IBO-Komponenten werden zum "automatischen committen" sowas ähnliches machen, oder? Hat diese Lösung irgendwelchen drastischen Einfluss auf die Performance?

Gruß

Mathia

[Torsten Grundke]

Hallo Mathias,

wenn die Daten einer Tabelle z.B. in einem DBGrid angezeigt werden sollen müssen sie auf dem Client-Rechner zur Verfügung stehen. Wenn ein sehr großer Datenbestand zum Client übertragen werden muß, kann das sehr schnell zu einem Performance Problem führen. Um dieses Problem zu vermeiden werden im Bedarfsfall nicht alle Daten sofort übertragen sondern erst zu gegebener Zeit. Das geht aber nur wenn die Transaktion offen gehalten wird (mehrfaches Öffnen und Schließen der Transaktionen könnte zu Problemen im anzuzeigenden Datenbestand führen).

Zu den IBO: Ich glaube schon das es eine ähnliche Lösung ist.

Performanceeinbußen sollten nur bei Massen-Inserts auftreten (mehrere 10- oder Hunderttausende Datensätze).

Tschüß

Torste

[Andreas Kosch]

Hallo,

in der Tat ist IBX an dieser Stelle etwas unhandlicher als die BDE. Bei der BDE war der AUTOCOMMIT-Modus die Voreinstellung, wobei man bei Bedarf jederzeit zur expliziten Transaktionssteuerung umschalten konnte. Bei IBX steht dieser Komfort nicht zur Verfügung, so dass sich der Entwickler selbst darum kümmern muss.

Wenn nur wenige Benutzer mit dieser InterBase-Datenbank arbeiten und regelmässig ein Backup/Restore-Zyklus abgearbeitet wird, könnte man im eigenen Programm das <b>AfterPost</b>-Ereignis der Datenmenge auswerten und dort die Methode <b>CommitRetaining</b> aufrufen. In diesem Fall übernimmt der InterBase alle momentanen Server-Ressourcen (inklusive der Ergebnismenge einer aktiven SELECT-Abfrage) in den Kontext der neu gestarteten Transaktion. Somit bleiben auch die Daten im TDBGrid etc. auch nach dem Aufruf von CommitRetaining sichtbar:
<pre>
procedure TDM.IBDSRedakteurAfterPost(DataSet: TDataSet);
begin
IBTransactionMain.CommitRetaining;
end;
</pre>
Ich würde daher <b>keine</b> neue Komponente ableiten, die dies automatisch macht, denn damit gibt man die Flexibilität auf. Außerdem würde ich anstelle von TIBQuery zu <b>TIBDataSet</b> wechseln, mit TIBQuery macht man sich das Leben nur unnötig schwer. Wenn andere SQL-Anweisungen als SELECT ausgeführt werden sollen, ist <b>TIBSQL</b> die IBX-Komponente der ersten Wahl. Hinter TIBQuery und TIBTable verbergen sich Kompatiblitäts-Komponenten für den leichteren Umbau einer bereits vorhandenen BDE-Anwendung. Allerdings unterstützen diese beiden IBX-Komponenten nicht alle Leistungsmerkmale, so dass beim Zugriff auf eine Dialect 3-Datenbank (in der die neuen InterBase 6-Sachen genutzt werden) Probleme auftreten.

&#10

[Torsten Grundke]

Hallo Andreas,

hast Du nicht schon mehrfach auf die Nebenwirkungen von CommitRetaining hingewiesen?

Zu meinem Vorschlag, Mathias wollte den Aufwand so gering wie möglich halten und wenn er sich der Einschränkungen(Selbstgeiselung) bewußt ist wäre es eine Variante.

Tschüß

Torste

[Andreas Kosch]

Hallo,

in der Tat hat CommitRetaining einige Nebenwirkungen, daher war in meiner Antwort ja auch die Einschränkung "<i>Wenn nur wenige Benutzer mit dieser InterBase-Datenbank arbeiten und regelmässig ein Backup/Restore-Zyklus abgearbeitet wird</i>" zu finden ;-)

In meiner IBX-Beispielanwendung <i>RedSys</i> wird als Kompromiss ein gesunder Mix zwischen CommitRetaining und Commit verwendet. Es läuft ja in der Praxis immer auf eine Abwägung zwischen Aufwand und Nutzer hinaus

[Mathias Berg]

Hallo,

vielen Dank für die Antwort. Überrascht bin ich über das Abraten von der TIBQuery bzw. deren Stellung als Kompatibilätskomponente. Ich entschied mich für diese Komponente, da sie von TDataset abgeleitet ist und somit die für mich relevanten Methoden (open, close, next) hat, UND die Methoden/Eigenschaften Parambyname, execsql,rowsaffected und recordcount (wobei recordcount in der Hilfe nicht dokumentiert ist?!) implementiert. Das ist bei allen anderen IBX-Komponenten nicht der Fall. Anfangs dachte ich auch die TIBSQL ist ideal, zumal ich auch keine Schnittstelle für datensensitive Steuerelemente brauche) aber die bietet das halt nicht...
Welche Dialect 3 Sachen kann ich da nicht nutzen

[Andreas Kosch]

Hallo,

nur ein Beispiel für die TIBQuery-Einschränkungen: Wenn in der Dialect 3-Datenbank eine Spalte <b>intern</b> den Datentyp INT64 (Large Integer) verwendet, kann TIBQuery nicht für das Aktualisieren/Einfügen von Datensätzen verwendet werden. Da TIBQuery TParams nutzt, stehen TLargeintField-Werte nicht zur Verfügung. Diese Beschränkung gilt nicht für TIBDataSet, da dort IBXSQLVAR genutzt wird.

Die IBX-Komponente <b>TIBDataSet</b> stellt mehr zur Verfügung als TIBQuery. Stellenweise unterscheidet sich nur der Zugriffsweg, zum Beispiel gilt dies über die Eigenschaft <b>Params</b>:
<pre>
IBDataSet1.Params[0].AsInteger := 24
IBDataSet1.Params.ByName[‘Field2’].AsString := ‘foo’
</pre&gt