Hallo,
also etwas läßt sich aber ganz allgemein sagen, nämlich daß die datensensitven Komponenten, also die des Tabs Datensteuerung der Komponentenpalette (tdbedit, tdbmemo, ...), absolut nichts mit unnötigen Zugriffen auf die Datenbank, Datensatzsperren, Transaktionsmechanismen, dem Erscheinen des
SQL-Cursors, usw zu tun haben. Die wissen überhaupt nichts von der Existenz von Datenbanken, und arbeiten auch mit abkömmlingen von TDataset zusammen (Memorydatasets, z.B. TRXMemorydataset, tdxmemdataset, TClientdataset...), die selber nichts von Datenbanken wissen.
Der Einsatz von TDBEdit und Konsorten hat mit Problemen der hier geschilderten Art
absolut nichts zu tun, und deshalb löst ein Verzicht auch nichts.
Auf den richtigne Einsatz der Datenzugriffs- und Verbindungskomponenten kommt es da schon eher an. Also in Verbindung mit
SQL-Servern keine TTable-komponenten.In Verbindung mit dem
SQL-Server empfiehlt sich
ADO, am besten TBetterAdoDataset, mit Commandtype cmdText.
Nun kann man nach dem Laden den Netzwerkstecker ziehen, und alles tun, außer Post oder Refresh, inclusive scrollen, edit und undo, ohne daß der Client daß merkt, wie aber ein Client bei abgezogenem Netzwerk Sperren auf dem Server macht, müßte mir mal jemand erklären. Sollte das aber immer noch nicht reichen, kann man dieses Dataset auch in einem Remotemodus betreiben, genau wie TClientdataset, dann kan man sogar lokal posten, ohne den Server zu belästigen, und dann nur zu einem akkumulierten Datenabgleich den Server connecten.
Aber nochmal: all dies hat mit den visuellen datensensitiven Komponenten nichts zu tun.
Grüsse
Woki