Verursacht DBEdit viel Traffic im SQL Server?

[rbest]

Hallo Kollegen. Ein Kollege behauptet, dass die DBEdit-Komponenten sehr viel DB-Traffic verursachen, und zwar jeder Mausklick ins Feld. Ist da was dran oder ist es nicht so, dass die DB nur bei open oder post, usw. abgerufen wird? Wer kann mir dazu konkrete Tips geben? Besten Dank im Voraus.

[r_kerber]

Hallo rbest,

zunächst erst einmal herzlich willkommen in der Delphi-Praxis.
Ich kann mir nicht vorstellen, dass ein einfaches Anklicken eines DBEdit-Feldes Traffic erzeugt. Wenn Dir die Daten angezeigt werden, dann hast Du ja vorher ein SQL SELECT an die Datenbank geschickt und eine Antwortmenge erhalten. Genau diese wird in den den datensensitiven Controls angezeigt. Traffic wird erzeugt, wenn Du Änderungen an die DB zurückschreibst bzw. wenn weitere Datensätze nachgeladen werden, da Du durch die Datensätze browsed (ein scheußliches Denglisch ).

[rbest]

hi r_kerber,
danke für die schnelle Nachricht, bis jetzt habe ich noch nichts unternommen. Mittlerweile kann ich das angebliche Problem näher definieren. Und zwar soll es innerhalb kurzer Zeit auf der DB (wir verwenden MS SQL Server) sehr viele Sperren geben, wenn man die DBEdit-Komponenten verwendet.
Schönes Wochenende!

[r_kerber]

Hallo rbest,

Sperren sollte es eigentlich nur geben, wenn die Datenmenge in den Edit-Modus versetzt wird. Interessant wäre zu wissen, ob Du auf die Datenbank mit TTable oder TQuery zugreifst. Bei TTable könnte ich mich mir vorstellen, dass ein Ändern des Wertes im DBEdit implizit ein Setzen in den Edit-Modus auslöst.

[woki]

Hi,

hat dieser Kollege öfter komische Träume, ich meine, welchen Grund führt er eigentlich für seine Argumentation an.

Also, die datensensitiven Komponenten, und insbesondere DBEdit sind für Zugriffe auf die Datenank ja nicht verantwortlich, sondern die von Tdataset abgeleiteten Komponenten handeln das.

Ein einfacher Versuch: Netzwerkabel abziehen zeigt, Datenbankzugriffe nur beim Datenabholen oder beim Zurückschreiben, zwischendurch kann man auf dem Client machen was man will, und nach Lust und Laune in den TDBedits rumklicken. Mit dem TClientdataset oder dem Remotefähigkeiten von ADO kann man das noch weiter entkoppeln und stärker kontrollieren

Grüsse
Woki

[Marcel Gascoyne]

So allgemein kann man hierzu keine Antwort geben. Der Einsatz von TTable bei SQL Server Datenbanken ist auf jedenfall nicht zu empfehlen. Im Extremfall sperrst Du die gesamte Tabelle für andere Benutzer solange Deine TTable aktiv ist (hängt von Deinem Transaktionstyp ab).

Versuch es mal mit einer Query Komponente und einem Client Dataset (falls Deine Delphi Version dies unterstützt). Die Daten werden dann auf Deinem Client zwischengespeichert. Zugriffe auf die Datenbank erfolgen dann nur noch bei Änderungen eines Datensatzes. Achte auch darauf das Du die Transaktion zum SQL Server so schnell wie möglich beendest.

Gruß,
Marcel

[OLLI_T]

Hallo Marcel!

Ich stimme Dir völlig zu und gehe sogar noch einen Schritt weiter. Ich setzte in meinen Interbase C/S Anwendungen nur TIBDatabase, TIBTransaction und TIBSQL ein. Sämtliche Änderungen werden über Stored Procedures durchgeführt. Datensensitive visuelle Kompos befinden sich nicht mehr in meiner Komponentenpalette. Stattdessen nutze ich intensiv ein aufgebohrtes Listview.

Was soll ich sagen, die Resonanz der Anwender gibt mir recht. Wenn bei jedem Tastendruck / Mausklick die SQL-Eieruhr kommt, wird das "bad day" Video in so manchem Büro bittere Realität. Ein guter Test ist es auch, das Mauskabel durchzuschneiden ...

Gruss

OLLI

[woki]

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

[rbest]

Hi r_kerber und Kollegen,

ich verwende TADOConnection und TADODataSet, sowie TDataSource - weder TTable, noch TQuery. Und dann eben die TDB-Komponenten (zumindest bisher, solange ich nicht sicher bin, dass die meine ca. 150 User ausbremsen). Grüsse aus Memmingen.

[Marcel Gascoyne]

Zitat von woki:

Aber nochmal: all dies hat mit den visuellen datensensitiven Komponenten nichts zu tun.

Solange Du nicht im Transaktionsmodus "Repeatable read" oder "Serializable" arbeitest gebe ich Dir vollkommen Recht. Beim SQL Server sorgt dies beim lesenden Zugriff aber dafür das die Shared-Locks erst beim Ende der Transaktion freigegeben werden.

Daher mein Vorschlag mit dem ClientDataset: Erst Daten ins ClientDataset holen und dann mit den datensensitiven Steuerelementen arbeiten.

Gruß,
Marcel