Hallo Leute,
also dBExpress ist doch das letzte! Ich habe jetzt den halben Tag rumgefrickelt und letztendlich die DOA-Komponenten bestellt, aber wurmen tut’s mich doch.
Wie schafft man es, das die Änderungen wieder in die DB geschrieben werden? Es kann doch nicht sein, dass ich das händisch machen muß. Der Provider tut’s auf jeden Fall nicht.
Bei den Demos geht das auch nicht, die ändern nur im ClientDataSet.
Hat jemand einen Plan?
Danke
nic
Sinnlose Antwort 
Ich kann die Frage zwar nicht beantworten, teile aber deine Erfahrungen, dass das Zeug nix taugt. Bin schnell wieder auf ADO/dbGO zurück…
Hi Nic,
also dBExpress ist doch das letzte!
Ich habe mich ebenso eine zeitlang mit DBExpress versucht. Wenn man den Umgang mit ClientDataSets, den DB-Komponenten und der BDE gewohnt ist, mag es eine gute Sache sein. Ohne ClientDataSets hat die Unidirektionialität von DBExpress aber derart viele Nachteile, dass ich - wie Roger - auf ADO/MSSQL umgestiegen bin und Queries nutze.
Wie schafft man es, das die Änderungen wieder in die DB
geschrieben werden?
Das sollte das ApplyUpdates() des ClientDataSets machen. Um die Transaktionen kurz zu halten muss diese Methode immer nur dann aufgerufen werden, wenn die Änderungen im ClientDataSet fertig geschrieben wurden.
Wenn Du bei DBExpress eine Transaktion startest, kannst Du innerhalb derselben Verbindung nur entweder schreiben oder lesen, aber nicht beides. Deshalb muss das ClientDataSet als Puffer dienen.
Ciao,
Rudy
Hallo
Nach allem was du da schreibst, scheinen aber Concurrency-Probleme bei dieser Technik sprichwörtlich „vorpgrammiert zu sein“. (ClientDataSets) die verbindungslosen „offline“ CLient-DataSets gefallen mir bei ADO.NET eigentlich auch nicht so deswegen…
Hi,
Nach allem was du da schreibst, scheinen aber
Concurrency-Probleme bei dieser Technik sprichwörtlich
„vorpgrammiert zu sein“.
Es gibt in der Tat ein erhöhtes Risiko, dass die Daten, die jemand sieht und lokal ändert, auf dem Server schon lange nicht mehr aktuell sind und munter geändert werden kann, bis die Daten schlussendlich am Server landen. ApplyUpdates() läuft dann entweder einfach schief (wenn z.B. ein Update auf einen DS erfolgen soll, der zwischenzeitlich gelöscht wurde) oder der letzte überschreibt einfach. Diese Gecache gefällt mir auch nicht, deswegen verwende ich lieber bidirektionale Queries und benutze eine eigene Technik zur Sperrung von Datensätzen, immer auf einzelne Eingabeformulare bezogen.
Der Sinn der ClientDataSets ist die serverseitigen Locks während einer Transaktion zu verringern, indem diese eine möglichst kurze Zeit dauern, nämlich nur während des Schreibvorgangs. Nur so kann auch die Benutzung eines unidirektionalen Systems funktionieren. Auf die Query reduziert ist DBExpress eine Zumutung.
die verbindungslosen
„offline“ CLient-DataSets gefallen mir bei ADO.NET eigentlich
auch nicht so deswegen…
.NET programmiere ich nicht, aber bei ‚offline-ClientdataSet‘ sträuben sich meine MultiTier-Haare Ohne eine zuverlässige Methode, die Gültigkeit der Daten für jeden Client zu garantieren, kommt mir das reichlich unsicher vor. Die DB-Komponenten von Delphi mag ich sowieso nicht verwenden.
Ciao,
Rudy