Hi,

das hier wird jetzt etwas theoretisch. Na ja, ganz ohne gehts nicht. Die normale Vorgehensweise: beim Lesen von Daten aus einer DB wird folgendes gespeichert (im Hauptspeicher, nicht Festplatte) : eine Kopie des gelesenen Datensatzes (also der Ursprungszustand), eine weitere Kopie, die bearbeitet wird (mit DBedit usw.) und eine Kopie des geänderten Datensatzes (die mit den Daten auf dem Server verglichen werden kann).

Bei letzterem kann es nun vorkommen, daß zwischenzeitlich von einem anderen User eine Änderung am Datenbestand vorgenommen wurde, so daß die Sicherungskopie nicht mehr mit den gespeicherten Daten übereinstimmt. Hat man nun einen Datensatz mit 100 Feldern und nur eine Tel.Nr. wurde geändert, dann wäre es wohl sinnvoll, die von woanders geänderte Nr. in die selber geänderten Daten zu übernehmen, anstatt die Meldung zu bringen : "Datensatz wiurde geändert, sie müssen alle 99 Felder, die sie gerade eingegeben haben neu eingeben".

Sehe ich das richtig, wird die am Anfang beschriebene Methode auch von einem BDR (siehe Titel) ausgeführt. Nur, darüber finde ich absolut nichts. Das ganze hat auch etwas mit dem MultiGen-Prinzip von IB zu tun. Da dürfte es wohl mindestens genauso viele BDR geben, wie Transactions.

Ja und nu? Wer weiß etwas zu dem Thema ?

War klar, daß hier keiner so schnell was postet. Das geht sehr tief. Folgendes habe ich aber selber schon herausgefunden :

Jedes Dataset hat auch folgende Eigenschaften :

- Value
- OldValue
- NewValue

Also so ähnlich wie ich es beschrieben habe. Und ich könnte wetten, daß das im Zusammenhang mit dem dubiosen BDR steht. Was das ganze ist, weiß ich aber noch nicht.

Hi

hansa hat folgendes geschrieben:

Und ich könnte wetten, daß das im Zusammenhang mit dem dubiosen BDR steht. Was das ganze ist, weiß ich aber noch nicht

Kann ich mir nur schwer vorstellen. Diese Feldeigenschaften werden durch das DataSet bei CachedUpdates zur Verfügung gestellt. Die BDR's werden vom Transaktionsmanagement der Datenbank verwaltet. Dazu steht noch nicht mal was im API-Guide.

Gruss Lothar

LCS hat folgendes geschrieben:

...Die BDR's werden vom Transaktionsmanagement der Datenbank verwaltet. Dazu steht noch nicht mal was im API-Guide.

ha, muß ich denn immer in einem Wespennest rumstochern. Na gut, dafür wird mirs nie langweilig. Einiges habe ich aber doch gefunden. Aber zu wenig um es hier zu posten. Außer dem hier :
OldValue usw. "stehen nur zur Verfügung falls CachedUpates aktiviert ist, oder bei einem ClientDataSet." Was es genau mit beiden auf sich hat raff ich sowieso noch nicht. Und noch die (wahrscheinliche) Vermutung, daß zu jeder Transaction ein BDR gebildet wird. Es gibt nämlich noch eine Garbage-Collection (Müllsammlung), die irgendwann aus der Interbase-DB entfernt werden sollte. Irgendwie steht das schon alles im Zusammenhang.

folgendes ist mir gelungen (per Codevervollständigung )


Weiterhin habe ich folgende Vermutung, wie das ganze abläuft :

Beim Lesen wird zuerst Oldvalue besetzt. In Value werden die Daten editiert. Und zum Schluß in NewValue zwischengespeichert. Die DB prüft nun beim schreiben, ob das OldValue auf der Platte noch den selben Wert hat, wie das im Speicher. Also Lock, vergleichen, abspeichern, oder bei Differenzen : Exception ODER! und da will ich hin: notfalls selber eingreifen. Wurde während des Edit-Vorgangs zwischenzeitlich nichts anderes gespeichert, so wird das OldValue auf der Platte mit dem NewValue ersetzt. Oder es wird der alte Zustand wiederhergestellt. Ähnlich, wie bei einem Rollback. Und da kommt dann wieder der komische BDR ins Spiel.

Vielleicht liege ich da aber auch völlig daneben. Das ganze wäre aber etwas, was im Mehrplatz-Bereich funktioniert.