Unterschiedliches Updateverhalten

[Carsten Kauschmann]

Hallo,

ich beobachte bei mir ein merkwürdiges Verhalten beim Update von Datensätzen. Ich habe in meiner Datenbank 2 Aufträge. Beide Aufträge haben identische Feldinhalte, bis auf den Primär Schlüssel. Der Primarykey ist ein Integerwert der durch einen Generator erzeugt wurde. Setzt ich nun im ersten Auftrag ein datumsfeld auf das aktuelle Tagesdatum und führe ein Updatebefehl "Update Auftrag set erledigt_am = :datum" mit Query.Execsql aus braucht der Befehl mit StartTransaction und Commit wenige Sekunden. Aktualisiere ich den zweiten Auftrag benötigt die Aktualisierung ca. 1. Minute!!! Das umdrehen der reihenfolge, zuerst Auftrag 2, dann Auftrag 1 führt zum gleichen Ergebnis: Auftrag 2 1Minute, Auftrag 1 Sekunden. Ich verwende Interbase 5.5 und Delphi 4. Hat jemand schon mal ein ähnliches Verhalten beobachtet und kennt eine Lösung?

mfg

[Andreas Kosch]

Hallo,

was protokolliert der <b>SQL-Monitor</b> mit? Über den SQL-Monitor kann geprüft werden, wann und wodurch diese Zeitverzögerung entsteht. Es gibt da mehrere mögliche Ursachen: <br>
- wenn die Transaktion <b>WAIT</b> verwendet, kann auf das Ende einer anderen Transaktion gewartet werden <br>
- beim sogeannten <b>FETCH ALL</b>-Problem lädt die BDE bei einem <b>Hard Commit</b> alle Datensätze der aktuellen Datenmenge zum Client.<br>
- Seiteneffekt durch feuernde <b>Trigger</b>. <br&gt

[Kai Möller]

Hallo Carsten,

vom Verhalten der Datenbank sieht es für mich so aus, als würde
sie einen 'Sweep' machen. Der allerdings dürfte bei der vorherigen Änderung nur einer Tabellenzeile noch nicht auftreten. Wird evtl. doch noch mehr upgedatet?

Gruß Ka

[Carsten Kauschmann]

Hallo Andreas,

Der SQL-Monitor zeigt alle Datensätze der aktuellen Datenmenge geladen werden! Als das was du als Fetch All Problem beschrieben hast.
Was kann man dagegen tun?

An Kai: Der Database Sweep ist auf 0 gesetzt. Es wird keine weitere Tabelle aktualisiert.

Gruß Carste

[Andreas Kosch]

Das sogenannte <b>FETCH ALL</b>-Problem tritt immer dann auf, wenn die Anwendung nicht optimal an C/S ausgerichtet wurde. Um das Problem zu beseitigen, gibt es mehrere Alternativen: <br>
1. Man hält sich an die C/S-Spielregeln und sorgt dafür, das die vom InterBase aufgebaute Ergebnismenge nur wenige Datensätze enthält. In diesem Fall sind die Auswirkungen eines <b>Hard Commit</b> nicht spürbar (beim einem Hard Commit verwirft der InterBase auf der Server-Seite die Ergebnismenge, so das die BDE alle noch nicht angezeigten Datensätze "zu retten versucht", indem diese auf den Client geladen werden). <br>
2. Man umgeht (teilweise) das Problem, indem auf ein <b>Soft Commit</b> gewechselt wird. In der <i>BDE-Verwaltung</i> wird dazu der Wert <b>4608</b> in der Spalte <b>DRIVER FLAGS</b> des InterBase-Treibers eingetragen (4608 = REPEATABLE READ + Soft Commit). Allerdings hat das einige Nebenwirkungen für das weitere Programmverhalten.

Eine umfassendere Betrachtung dazu ist in meinem Beitrag <i>Client/Server Secrets</i> in der Ausgabe 1/99 von DER ENTWICKLER oder noch umfangreicher in meinem Buch <i>Client/Server Datenbankentwicklung mit Delphi</i> zu finden

[Carsten Kauschmann]

Hallo Andreas,

danke für den Hinweis. Ich hatte vergessen eine Datenmenge zu schliesen nach einen Select. Jetzt funktioniertes wieder wie erwartet.

danke Carste