Announcement

**Andreas Kosch** · 23.09.2000, 08:35

Hallo,

zu Frage 1: 
Dank der Multigenerationenarchitektur (Versioning) des InterBase ist dies das Standardverhalten. Die TIBTransaction-Instanz sollte dabei die folgende Konfiguration verwenden:
<pre>
read_committed
rec_version
nowait
</pre>

zu Frage 2: 
Eine Transaktion sollte in der Regel immer mit Commit best�tigt werden, der Einsatz von CommitRetaining sollte aufgrund der damit verbundenen Nebenwirkungen nur in begr�ndeten F�llen erfolgen. Da mit einem Commit automatisch auch das Schlie�en des Datasets verbunden ist, erh�lt der Client beim anschliessenden �ffnen automatisch eine neue Transaktionsnummer und somit den neuesten Stand des Datensates.

zu Frage 3: 
Generell ist es eine gute Idee, alle "Nachschlagetabellen" lokal im Client zwischenzupuffern, so dass die Datenmenge nur kurzzeitig f�r das Kopieren der Daten offen sein muss. Im Fall von IBX kann man dazu eine TClientDataset-Instanz verwenden (ab Delphi 6 soll TClientDataset auch in der Professional-Version von Delphi enthalten sein). Die BDE- und ADO-Leute haben es da besser, hier stehen mehr Alternativen zur Verf�gung.

Au�erdem ist es in einer typischen C/S-Umgebung un�blich, dass ein Datensatz aus einer offenen Datenmenge ausgew�hlt und ge�ndert wird. Der "normale" Weg sieht statt dessen so aus: 
1. Benutzer ruft ein Auswahlfenster auf, in dem via SELECT Datens�tze zur Auswahl angeboten werden. 
2. Nach der Auswahl wird diese Datenmenge und das Auswahlfenster geschlossen und der konkrete Datensatz einzeln (DBEdits etc.) im Hauptfenster angezeigt. 
3. Beim UPDATE ist nun nur ein einziger Datensatz in der Datenmenge, die nach dem COMMIT automatisch geschlossen wird. 
4. Soll ein weiterer Datensatz bearbeitet werden, wiederholt sich das Ganze. 
In diesem Szenario wird CommitRetaining �berhaupt nicht ben�tigt, der InterBase kann somit sehr effektiv arbeiten.

zu Frage 4: 
Das kommt darauf an. Eine eigene TIBTransaction-Instanz wird nur dann ben�tigt, wenn die Datenbankzugriffe als Transaktion unabh�ngig von den anderen Zugriffen gesteuert werden sollen. Es ist besser, zwei Instanzen einzusetzen als alle Datenmengen �ber CommitRetaining am Leben zu erhalten, obwohl dies nicht in jedem Fall notwendig ist.

zu Frage 5: 
In einem guten InterBase-Buch. IBX setzt im Bereich der Transaktionen direkt auf den InterBase auf, ohne selbst einzugreifen (von minimalen Ausnahmen einmal abgesehen). Somit sind spezielle IBX-B�cher nicht notwendig (was die Tranaktionssteuerung angeht).
&#10

**Georg Ledermann** · 23.09.2000, 16:55

Hallo,

erst mal vielen Dank f�r die ausf�hrliche Antwort. Dennoch m�chte ich in einigen Punkt noch etwas ins Detail gehen bzw. nachhaken:

zu 1) Die angegebenen Parameter habe ich wie angegeben gesetzt, d.h. es ist "read-commited" eingestellt. Dennoch erh�lt ein zweiter User, der einen bereits ge�nderten Datensatz �ndert, KEINE Fehlermeldung. Woran kann das liegen? Eine �nderung auf "no_rec_version" bringt auch nichts, da dies nur eine Fehlermeldung bringt, wenn der andere User den Datensatz in einer OFFENEN Transaktion bearbeitet, hat er sie bereits COMMITed, passiert auch hier nichts.

zu 3) Ich sehe ein, dass in einer C/S-Umgebung andere Regeln auch f�r die Benutzeroberfl�che entstehen. Dennoch soll aber doch bestimmt direkt in einer Liste ein Datensatz gel�scht werden k�nnen. Hier stellt sich aber eine weitere Frage, die ich am folgenden Ablauf verdeutlichen m�chte:

- TIBDataset mit gew�nschtem SelectSQL (das mehrere Datens�tze zur�ckliefert) und DeleteSQL belegen
- TIBDataset.StartTransaction
- TIBDataset.Open, Anzeige der Daten in einem Grid
(Transaktion ist nun so lange offen, wie der User es will)
- User will editieren -> TIBDataset.Commit, dann im neuen Fenster neue Query abschicken, die nur den einen Datensatz bringt
(jetzt kommt's

- User will l�schen -> TIBDataset.Delete aufrufen, wodurch die eingestellte DeleteQuery aufgerufen wird, ABER UNTER WELCHER TRANSAKTION????
- User schlie�t das Listenfenster -> TIBDataset.Commit/Close

Werden SELECT und DELETE in der gleichen Transaktion ausgef�hrt? Wie wird sichergestellt, dass ein L�schen sofort commited wird? Ist hier ausnahmsweise die Verwendung von CommitRetaining sinnvoll?

zu 5) Da die Auswahl an InterBase-B�chern sehr gering ist, ist es ein Leichtes, alle Verf�gbaren zu kennen; daraus kann man prima die Funktionsweise von InterBase erlernen. Was ich jedoch bisher kaum gesehen habe, ist eine intensive Auseinandersetzung mit InterBase auf Applikationsebene. Man liest zwar st�ndig, dass z.B. Transaktionen nur so kurz wie m�glich offen gehalten werden sollen etc., aber wie das am besten mit Delphi und den verf�gbaren Komponenten (IBX/IBO) gemacht werden kann, findet sich kaum, zumindest nicht in zusammenh�ngender Form. Was ich suche ist eine vern�nftige IB-Applikations-"Architektur" (am liebsten auf Basis von IBX), die man f�r eigene (neue!) Projekte �bernehmen kann. Ich stehe hier vor der Aufgabe, eine Applikation zu bauen, die um die 200 Tabellen in der IB-Datenbank halten muss. Da ist allein die Frage nach einer geschickten Aufteilung in Datenmodule nicht trivial.
Ich werde mich jetzt nochmal intensiv mit IBSrcArc besch�ftigen, vielleicht hilft mir das.

Bleibt mir ansonsten nur ein Workshop bei HK? ;-)

Beste Gr��e,
Geor

**Andreas Kosch** · 25.09.2000, 18:49

Hallo,

zur Frage 1: 
Die Vorgehensweise muss nur in einem Punkt erweitert bzw. besser erkl�rt werden :-) 
1. Benutzer startet Transaktion 
2. Benutzer liest Datensatz ein 
3. Benutzer macht einen beliebigen Dummy-Schreibzugriff auf diesen Datensatz, damit erh�lt er die eigene Transaktionsnummer 
4. Benutzer editiert in Ruhe diesen "gesperrten" Datensatz 
5. Benutzer macht sein UPDATE und Committed die Transaktion 
Wenn der zweite Client diese Schritte abarbeiten will, erh�lt er im Schritt 3 immer dann ein Veto vom InterBase (no_rec_version), wenn vor ihm bereits ein anderer Client dies aufgerufen hat.

zur Frage 3: 
Hier w�rde ich in jedem Fall nach dem Abschicken der DELETE-Anweisung ein COMMIT aufrufen und die Datenmenge neu aufbauen lassen (d.h. neues SELECT).

zur Frage 5: 
Derartige Fragen sind immer eines der Hauptthemen der Workshops zu den Entwickler-Konferenzen. Zum Beispiel k�mmere ich mich hier zur Entwickler-Konferenz am Freitag von 09..17 Uhr um dieses Thema. Falls es eine neue Auflage des Buchs gibt, werde ich dieses Thema aber auch dort ansprechen (wenn ich die zus�tzliche Seitenanzahl daf�r "genehmigt" bekomme)

**VolkerJ** · 03.10.2001, 10:12

Hallo Andreas, 
ich gebe georg recht, es gibt wirklich wenige Beispielanwendungen in diesem Bereich.Theorie ist ja sch�n und gut aber ein praktisches Beispiel ist noch besser ) 
Ich habe auch eine Frage zu Multiuser - Anwendung undzwar: 
wie l�uft das mit " Set Transaction isolation level snapshot table stability; " wird dabei der datensatz gesperrt oder die ganze Tabelle? 
Womit erzeuge ich die Transaction ? mit TIBTransaction oder wie kann ich das steuert? 

Regard

**VolkerJ** · 03.10.2001, 10:13

Hallo Andreas, 
ich gebe georg recht, es gibt wirklich wenige Beispielanwendungen in diesem Bereich.Theorie ist ja sch�n und gut aber ein praktisches Beispiel ist noch besser ) 
Ich habe auch eine Frage zu Multiuser - Anwendung undzwar: 
wie l�uft das mit " Set Transaction isolation level snapshot table stability; " wird dabei der datensatz gesperrt oder die ganze Tabelle? 
Womit erzeuge ich die Transaction ? mit TIBTransaction oder wie kann ich das steuert? 

Regards
Volker Jahn

**Andreas Kosch** · 04.10.2001, 06:13

Hallo,

die Diskussion endete am 22. September 2000 - ist also �ber ein Jahr alt. Inzwischen gibt es komplexe IBX-Beispielprojekte: 
a) hier im Forum unter Delphi | IBX | RedSys, und 
b) in meinem Buch InterBase Datenbankentwicklung mit Delphi 
In meinem IBX-Buch ist auch das folgende Beispiel zu finden, dass diese "exotischen" Isolation Level aktiviert:
<pre>
procedure TForm1.RadioGroup1Click(Sender: TObject);
begin
IBDataSet1.Active := False;
IBDatabase1.Connected := False;
IBDatabase1.Params.Values['user_name'] := 'sysdba';
IBDatabase1.Params.Values['password'] := 'masterkey';
IBTransaction1.Params.Clear;
case RadioGroup1.ItemIndex of
1 : begin
with IBTransaction1 do
begin
Params.Add('read_committed');
Params.Add('rec_version');
Params.Add('nowait');
IBDatabase1.Connected := True;
IBDataSet1.Active := True;
end;
end;
2 : begin
with IBTransaction1 do
begin
Params.Add('nowait');
Params.Add('consistency');
Params.Add('lock_write=NameDerTabelle');
Params.Add('exclusive');
IBDatabase1.Connected := True;
IBDataSet1.Active := True;
end;
end;
3 : begin
with IBTransaction1 do
begin
Params.Add('nowait');
Params.Add('consistency');
Params.Add('lock_write=NameDerTabelle');
Params.Add('shared');
IBDatabase1.Connected := True;
IBDataSet1.Active := True;
end;
end;
end;
Memo1.Lines := IBTransaction1.Params;
end;
</pre>
�ber TIBTransaction.Params kann man alles das anfordern, was vom InterBase unterst�tzt und in seiner Dokumenation beschrieben wird. Es wird die komplette Tabelle gesperrt, wobei man sogar jeden Lesezugriff (SELECT) auf diese Tabelle blockieren kann

**VolkerJ** · 05.10.2001, 14:13

Vielen dank Andreas , 
ich habe mir dein neues Buch besorgt und kann das beispiel nachvollziehen.
Das Buch ist wirklich gut, gut Aufgebaut und immer Beispiele

Gru� Volker Jahn

Announcement

IBX: Transaktionen richtig nutzen

IBX: Transaktionen richtig nutzen

Comment

Comment

Comment

Comment

Comment

Comment

Comment