Announcement

**Andreas Kosch** · 07.04.2003, 06:46

Hallo,

zu Frage 1: Ja.

zu Frage 2: Ja.

zu Frage 3: Daf�r sieht IBX die Eigenschaft IdleTimer sowie das TIBTransaction-Ereignis OnIdleTimer vor. Im Unterordner RedSys ist ein Beispielprojekt zu finden, dass diesen Weg nutzt, um in regelm�ssigen Zeitabst�nden die Daten "anderer Benutzer" im TDBGrid auftauchen zu lassen. Der folgende Auszug stammt aus diesem Beispiel:

<pre>

{-------------------------------------------------------------------}
{ IBTransactionMain IdleTimer }
{-------------------------------------------------------------------}

{
Eine der Grundregeln in der C/S-Welt lautet, dass der Client niemals
die Zeitdauer einer Transaktion bestimmen darf. Dabei muss der Entwickler
gleich 2 F�lle betrachten:
a) Transaktionsdauer bei INSERT/UPDATE/DELETE (X-Locks)
b) Transaktionsdauer bei SELECT (S-Locks)
Die Schreibzugriffe verursachen ein X-Lock (Exklusive Sperre), daher
muss die Zeitdauer dieser Sperre (= G�ltigkeitsdauer der Transaktion)
minimiert werden.
Die Lesezugriffe verursachen ein S-Lock (Gemeinsame Sperre), wobei dank
der Multigenerationenarchitektur des InterBase dies nicht so gravierende
Folgen wie ein lange wirksamer X-Lock hat. Allerdings sollte auch hier
die Zeitdauer der Transaktion so kurz wie m�glich sein. Was bei der BDE
kein Thema war (dank AUTOCOMMIT und der Intelligenz von TTable/TQuery),
kommt bei IBX mit dem Dringlichkeitsvermerk auf die Tagesordnung. Bei
IBX muss sich der Entwicklungs um alles selbst (!) k�mmern, d.h. er
hantiert direkt mit den InterBase-Transaktionen. Und da sogar ein einfacher
Lesezugriff (SELECT) nur im Kontext einer Transaktion ausgef�hrt werden
kann, gibt es ein Problem. Um dieses zu l�sen, gibt es mehrere M�glichkeiten:
a) Verzicht auf TDBGrid, Daten werden nur gelesen, in TEdits kopiert und
danach die Transaktion �ber COMMIT beendet. IBX schliesst darauf alle
aktiven Datenmengen (was hier nicht zum Problem wird).
b) Verzicht auf TDBGrid kommt nicht in Frage, daher wird die Datenmenge
sofort in eine In-Memory-Table (TClientDataSet oder �hnliches)
kopiert und danach die Transaktion �ber COMMIT beendet. IBX schliesst
darauf alle aktiven Datenmengen (was hier nicht zum Problem wird).
Allerdings steigt der Aufwand, wenn die Daten auch editierbar sein
sollen (Briefcase-Modell).
c) Verzicht auf TDBGrid kommt nicht in Frage, Mehraufwand f�r In-Memory-
Tabellen kommt nicht in Frage. In regelm�ssigen Abst�nden wird
CommitRetaining aufgerufen - wobei IBX die Datenmenge offen h�lt und
sich die aktuellen Datensatzposition nicht �ndern.
d) Verzicht auf TDBGrid kommt nicht in Frage, Mehraufwand f�r In-Memory-
Tabellen kommt nicht in Frage. In regelm�ssigen Abst�nden wird
Commit aufgerufen - wobei IBX die Datenmenge jedoch schlie�t. Wenn
nach dem erneuten �ffnen der Datenmenge die "alte" Position sichtbar
sein soll, muss dieser Datensatz vorher �ber ein eindeutiges Merkmal
gespeichert werden.
Das Programm soll sich generell den vom Bearbeiter zuletzte aufgerufenen
Beitrag merken und diesen Datensatz beim n�chsten Start sofort wieder
anzeigen. Es liegt auf der Hand, diese Funktion auch f�r die L�sung des
Transaktionsproblems zu nutzen:
1. TIBTransaction-Eigenschaft IdleTimer: Immer dann auf 10000 Millisekunden
setzen, wenn die Datenmenge IBDSBeitrag im State dsBrowse ist,
anderenfalls den IdleTime �ber die Zuweisung von 0 deaktivieren
2. TIBTransaction-Eigenschaft DefaultAction: TACommit -> IBX schlie�t dabei
automatisch alle zu diesem Zeitpunkt offenen Datenmengen, die dieser
TIBTransaction-Instanz zugewiesen waren.
3. TIBTransaction-Ereignis OnIdleTimer auswerten: Datenmengen neu �ffnen und
alten Datensatz �ber die Prim�rschl�sselwerte suchen
}

const
cIBDSBEITRAG_IdleTimer = 10000;

//{$DEFINE DebugIdleTimer} // Compilerdirektive ist auskommentiert

procedure TDM.IBTransactionMainIdleTimer(Sender: TObject);
begin
{$IFDEF DebugIdleTimer}
MessageBeep(0);
ShowMessage(Format('P: %d; A: %d, B: %D',
[FCurrentPublikationID, FCurrentAusgabeID, FCurrentBeitragID]));
{$ENDIF}
DoOpenBeitrag;
end;

{
Das Fenster f�r die Bearbeitung der Beitr�ge zu einer Ausgabe einer
Publikation wird ge�ffnet. Das Programm muss genau den Datensatz
wieder aktivieren, der vom Bearbeiten beim letzten Aufruf ausgew�hlt
wurde. Dazu verwendet diese Methode schnellere und effektivere
Alternativen zur Locate-Methode (die jedoch ebenfalls genutzt werden
k�nnte).
Nach dem Einlesen aller Datenmengen wird gleich ein CommitRetaining
abgesetzt, um die aktuellen S-Locks zu entfernen.
}

procedure TDM.DoOpenBeitrag;
begin
FLocateMode := True;
if not IBTransactionMain.InTransaction then
IBTransactionMain.StartTransaction;
// Alle Datens�tze der Redakteur-Tabelle im Voraus einlesen
with IBQBeitragRedakteur do
begin
Active := True;
FetchAll;
end;
// zuletzt ausgew�hlte Publikation wieder aktivieren
with IBQBeitragPublikation do
begin
Active := True;
DisableControls;
try
while (IBQBeitragPublikationREIHEID.Value <> FCurrentPublikationID) and
(not EOF) do
Next;
finally
EnableControls;
end;
end;
// zuletzt ausgew�hlte Ausgabe wieder aktivieren
with IBDSSPBeitragAusgabe do
begin
Active := True;
DisableControls;
try
while (IBDSSPBeitragAusgabeAUSGABEID.Value <> FCurrentAusgabeID) and
(not EOF) do
Next;
finally
EnableControls;
end;
end;
// zuletzt ausgew�hlte Beitrag wieder aktivieren
with IBDataSetBeitrag do
begin
Active := True;
DisableControls;
try
while (IBDataSetBeitragBEITRAGID.Value <> FCurrentBeitragID) and
(not EOF) do
Next;
finally
EnableControls;
end;
end;
with IBQBeitragManuskript do
begin
Active := True;
FetchAll;
end;
IBQBeitragEditRedakteur.Active := True;
// S-Locks entfernen und IdleTimer aktivieren
IBTransactionMain.CommitRetaining;
IBTransactionMain.IdleTimer := cIBDSBEITRAG_IdleTimer;
FLocateMode := False;
end;

</pre>
P.S: Detaillierter wird das Ganze auch in meinem Buch InterBase-Datenbankentwickklung mit Delphi beschrieben

**Christian Storfinger** · 07.04.2003, 14:01

Hallo Hr. Kosch, 
besten Dank f�r Ihre Hinweise. Ich habe Ihre B�cher und werde mir den Abschnitt durchlesen. 
 
Mir fehlt allerdings noch die Ursache f�r das Problem. 
Kann man allgemein sagen, dass mit IBX meine Transaktion "lesen" zwar gestartet wird, aber durch das fehlende Commit und meinen Isolationslevel "Snapshot" nichts von weiteren �nderungen erf�hrt? Dann h�tte also das Setzen des OnIdleTimer-Intervalls nur den Sinn, dass ein regelm�ssiges Commit (oder besser CommitRetaining?) ausgef�hrt wird? 
Im obigen Beispiel fragen Sie ab, ob die Datenmenge im Status dsBrowse ist. Bei mir f�llt diese Transaktion "_lesen" nur das Auswahlgrid, ist also immer im dsBrowse. Dann k�nnte ich auch den OnIdleTimer fest auf 10000 lassen. Das w�rde dann bedeuten, dass alle 10 Sekunden die Datenmenge geschlossen und wieder ge�ffnet wird. Habe ich dann ab einer bestimmten Menge je nach Selektion Performanceprobleme? 
 
Ist es �berhaupt sinnvoll, f�r lesende und schreibende Zugriffe zwei verschiedene TIBTransaction-Objekte zu nutzen? Als Alternative k�nnte ich mir noch vorstellen, die Auswahlmenge in ein Stringgrid zu lesen und dieses nach Bedarf manuell zu aktualisieren. 
 
Vielen Dank f�r Ihre Hilfe, 
Christian Storfinge

**Christian Storfinger** · 08.04.2003, 10:18

Hallo Hr. Kosch, 
ich habe gestern den IdleTimer auf 10000 gesetzt und rufe im dazugeh�rigen Ereignis ein CommitRetaining auf. Ich starte jetzt manuell die Lesen-Transaktion und setze diese sogar nach dem Einf�gen auf active:=false und wieder active:=true sowie nach dem FetchAll sofort ein CommitRetaining. 
 
Leider �ndert das nichts an der Tatsache, dass ein neuer Datensatz erst beim Neustart der Anwendung sichtbar ist. 
 
Noch eine Frage: Wieso bezeichnen Sie Locate als effizienter? Nach der Delphi-Dokumentation und diversen anderen B�chern gibt es keine schnellere M�glichkeit als Locate... 
 
Besten Dank f�r Ihre Bem�hungen, 
Christian Storfinge

**Frank S�lter** · 08.04.2003, 10:42

Eigentlich ist das ganz einfach du must die Transaction die f�r dei Grid zust�ndig ist restarten (Active:=False Active:=True) und da sind die Datens�tze leider must du danach auch den Dataset wieder Activieren und warum nutzt du nich einfach TIBSQL oder willst du in der Grid auch daten �ndern ?

**Patrick Sack** · 08.04.2003, 10:54

Hallo,
 
 ich m�chte nicht direkt in die Diskusion eingreifen sondern zu n�chst noch eine etwas andere Methode vorstellen:
 http://www.entwickler-forum.de\WebX?14@@.ee868b5
 Diese geh�rt wohl zu dem Punkt:
 >c) Verzicht auf TDBGrid kommt nicht in Frage, Mehraufwand f�r In-Memory-
 >Tabellen kommt nicht in Frage. In regelm�ssigen Abst�nden wird
 >CommitRetaining aufgerufen - wobei IBX die Datenmenge offen h�lt und
 >sich die aktuellen Datensatzposition nicht �ndern.
 
 Zu beachten ist hier die Warnungen von A.Kosch in #3:
 "... der Isolationsgrad READ COMMITTED (Committed-Lesen) wird im SQL-Standard nur als Kompromiss betrachtet, da er gegen eine der Transaktionsregeln verst�sst (innerhalb der eigenen, laufenden Transaktion sollte der Datenbestand immer so zu sehen sein, wie er beim Start der Transaktion war). Somit ist f�r puristische SQL-Fans anstelle von READ COMMITTED der Level REPEATABLE READ (alias SNAPSHOT beim InterBase) die 1. Wahl, denn nur hier werden die Anforderungen aus dem Standard erf�llt. Der InterBase muss intern bei READ COMMITTED mehr arbeiten als bei SNAPSHOT, so dass es ein Abw�gung zwischen Aufwand und Nutzen ist."
 
 mfg
 P

**Christian Storfinger** · 08.04.2003, 11:08

Hallo zusammen! 
 
Ich habe wohl nicht bedacht, dass auch nur-lesende Transaktionen committed werden m�ssen. Nachdem ich in meinem Auswahlgrid nicht editieren mu�/m�chte, werde ich wohl auf ein StringGrid umstellen und dieses manuell neu f�llen, wenn ich es f�r n�tig halte. 
 
@Frank: Ich habe den "Restart" der lesenden Transaktion schon implementiert. Die neuen Datens�tze erscheinen trotzdem nicht. Ich verwende im Transaktionsobjekt "Snapshot", das erscheint mir am sichersten. 
 
Gru�, Christia

**Frank S�lter** · 08.04.2003, 11:34

Wenn ich mich noch richtig erinnere (ich benutze kein TIBDataset mehr) giebt es in einigen Version von IBX ein Bug in der IBDataset was genau dein Problem beschreibt (ich weis nicht genau ob es das wahr) und ob es noch in der Aktuellen Version drin ist.
Deshalb teste doch mal die Grid mit einer TIBSQL zu f�lle

**Christian Storfinger** · 09.04.2003, 08:36

Hallo Frank, 
ich realisiere jetzt mein Auswahlgrid mit einem TStringGrid und aktualisiere wenn n�tig. 
 
Du f�llst Grids mit TIBSQL? 
Meines Wissens ist doch TIBSQL eine Einbahnstra�e zum Server z.B. f�r insert- oder update-Statements. Ich kann doch damit keine Ergebnismenge �ffnen mit active:=true, oder? 
 
Christia

**Frank S�lter** · 09.04.2003, 08:55

Tschuldige ich meine TIBQuer

**Christian Storfinger** · 11.04.2003, 17:36

Hallo zusammen! 
 
Ich habe mein Auswahlgrid umgebaut. Ich habe jetzt (doch) noch ein TDBGrid, gef�llt von einer TIBQuery und jetzt ein neues Problem mit dieses Kombination. 
 
Dazu mache ich gleich einen neuen Thread mit dem Titel "Seltsames Verhalten von TIBQuery bei Locate" auf... 
 
Christia

Announcement

Aktualisierungsproblem mit IBDataset

Aktualisierungsproblem mit IBDataset

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment