Grundlagen zu Cached Updates

[Georg Ledermann]

Hallo,

in einer Anwendung, die auf einer stark normalisierten Datenbank arbeitet, gibt es häufig Eingabemasken für Tabellen, die über mehrere Master-Detail-Verbindungen miteinander verbunden sind, dem Benutzer aber visuell als Einheit angeboten werden sollen.

Beispielsweise kann man sich eine Eingasbemaske für Kunden-Stammwerte (MASTER) vorstellen, zu denen mehrere Adressen (DETAILS) angelegt werden können. Der Benutzer soll jedoch nicht erst den Kunden eingeben, dann speichern, dann die erste Adresse eingeben, speichern, dann die zweite Adresse eingeben und wieder speichern. Die Eingabe soll vielmehr die Sichtweise des Benutzer unterstützen und damit auch nur einen einzigen Speichervorgang erfordern.

Hierfür bieten sich nach meinem Verständnis "Cached Updates" an: Erst werdern alle Eingaben quasi gesammelt (also den Eintrag in der Mastertabelle und die zwei Detaildatensätze) und dann mit entsprechenden ApplyUpdates in die Datenbank geschrieben.
Nachdem ich aber sehe, dass sehr Viele damit große Probleme haben, würden mich ein paar Grundlagen zum Thema "Cached Updates" und IBX interessieren. Die D5-Online-Hilfe gibt da nicht so viel her, das Buch von A.Kosch geht leider auch nicht auf IBX ein. Für Hinweise und Anregungen wäre ich sehr dankbar!

Gruß,
Georg

[Andreas Kosch]

Hallo,

das Thema <b>IBX</b> kommt in der Tat in meinem Buch kaum vor - allerdings war die Originalversion von Delphi 5 für eine Praxisanwendung aufgrund der massiven Bugs auch nicht brauchbar, so das ich zu diesem Thema lieber geschwiegen habe ;-) Erst jetzt bessert sich die Situation mit dem IBX-Beta-Update 4.1 (IBXDP5EBETAUP41.EXE) etwas.

Aus gutem Grund bezeichnet Borland seit 1999 das <b>ClientDataset</b>-Modell als Nachfolger für den bisherigen Cached Update-Mechanismus. Das der Cached Update-Implementierung der BDE zugrundeliegende Prinzip hat einige Design-Schwächen (zum Beispiel den Sonderfall eines NULL-Wertes beim Update), die dafür gesorgt haben, das Cached Updates nicht universell nutzbar waren. Bei komplexen Fällen musste man von Hand eingreifen.

Ein ClientDataset ist als Nachfahre von TDataset datenbankunabhängig und kann somit auch mit Daten umgehen, die von der BDE stammen. Ausserdem kann ein ClientDataset als TDataset-Nachfolger auch mit den restlichen Datenbank-Controls von Delphi verbunden werden. Da die Datenmenge eines ClientDatasets komplett im Arbeitsspeicher vorgehalten wird, ist ein schneller Zugriff auf die Daten möglich. Solange sich beide Enden der Provider-Verbindung auf dem gleichen Rechner befinden, ist keine MIDAS-Lizenz notwendig.

Somit stellen die TClientDatasets für die Implementierung einer "Cached Updates"-Funktion gleich 2 Alternativen zur Verfügung:

1. Alle Benutzerdaten werden in den ClientDatasets abgelegt. Beim Speichern aller Eingaben geht man im Programm zeilenweise durch die Datasets und schickt die vorgefundenen Daten über entsprechenden SQL-Anweisungen in die beteiligten Tabellen. Die ClientDatasets haben dabei nur die Funktion einer Speichertabelle, ohne das der MIDAS-Mechanismus für das automatische Updaten genutzt wird.

2. Die Anwendung greift über den MIDAS-Mechanismus auf den Provider zu, so das die von Borland bereitsgestellten Funktionen (ApplyUpdates, HandleReconcileError usw.) zur Verfügung steht. Wenn "Client" und Provider auf dem gleichen Rechner ( bzw. gleiches Programm) ausgeführt werden, ist keine MIDAS-Lizenz notwendig.

Falls die Enterprise-Version von Delphi 5 zur Verfügung steht, würde ich mich auf die ClientDatasets als Cached Update-Ersatz konzentieren. Borland hat auf seinen Web-Seiten einige TechDocs zu diesem Thema

[Georg Ledermann]

Danke für die ausführliche Antwort. Die Enterprise-Version habe ich zwar nicht vorliegen, aber das Thema "ClientDatasets" scheint es wert zu sein, dass man sich damit mal näher beschäftigt