Geschwindigkeitproblem

[Gregor Bartosinski]

Hallo zusammen ,

ich habe es geschafft eine runde Applikation mit MTS zu erstellen. Nun in der ersten Woche des Test kommen bekanntlich die Probleme zu tage, an die man nicht gedacht hatte . Das Problem der mir sorgen macht ist die Geschwindigkeit . Führe ich verschiedene SQL-Statments mittels TADOQuery durch, so läuft es sauber. Eröffne ich eine Tabelle (ca. 45.0000 Sätez) mittels TADOTable ( Table.open ), so dauert es bis zu 1 min. ohne großen Trafic auf dem Netz. Ich habe den Eindruck je größe die Tabelle desto langsamer wird die Erföffnung. Ist das bei MTS normal so ? Oder habe ich etwas vergessen . Übrigens an der Umgebung kann es nicht liegen . Der Server ist mit 1 GB Speicher und zwei Prozessoren 1 GHz bestückt. Betriebssystem ist Windows 2000 Server und die Datenbank ist der SQL 2000.

Vielen Dank im Vorraus.

Gruß Barto

[Andreas Kosch]

Hallo,

>Ist das bei MTS normal so ?

daran hat der MTS keine Schuld. Die Komponenten TADOQuery und TADOTable gehören in die Kategorie "Waschmittel-Werbung" - an diesen Dingern hat nur die Marketing-Truppe bei Borland Freude :-)

&gt;Eröffne ich eine Tabelle (ca. 45.0000 Sätez) mittels TADOTable ( Table.open ), <br>
&gt;so dauert es bis zu 1 min. ohne großen Trafic auf dem Netz.

Immer dann, wenn der Zugriff auf eine MS SQL Server-Datenbank über ADO aus dem MTS/COM+ heraus erfolgt, schaltet der MS SQL Server auf den Transaction Isolation Level <b>SERIALIZABLE</b>. Beim Aufruf von TADOTable.Open muss der Server alle (!) Datensätze der Tabelle als Ergebnismenge aufbauen. Je nach der vorgefundenen Tabellenstruktur (TIMESTAMP-Spalte vorhanden oder nicht), muss der Server ggf. alle Datensätze nach <i>tempdb</i> kopieren und massiv Sperren (Locks) setzen, um die Abschottungsregel der Transaktion (SERIALIZABLE) einzuhalten. Beim Setzen dieser Sperren muss der SQL Server solange warten, bis bereits vorgefundene Sperren andere Datenbankverbindungen freigegeben werden.

Lange Rede - kurzer Sinn: Man darf <b>niemals</b> alle Datensätze anfordern, sondern <b>TADODataSet</b> verwendet eine SELECT-Abfrage (oder noch besser eine Stored Procedure), die über eine geeignete WHERE-Einschränkung nur die <b>wirklich benötigten</b> Datensätze anfordert und zurückliefert.

Bei der Kombination von MS SQL Server, ADO und MTS/COM+ ist es auch in der Regel sinnvoll, wenn sowohl TADOConnection als auch TADODataSet den Konfigurationswert <b>clUseClient</b> für die Eigenschaft CursorLocation verwendet. Innerhalb einer Interface-Methode des MTS/COM+ Objekt wird die Datenbankverbindung (TADOConnection) erst angefordert, die Aktion aufgerufen und danach <b>sofort</b> die Datenbankverbindung wieder geschlossen. Dank dem automatischen Datenbankverbindungs-Pool von OLE DB hat dieses ständige Öffnen/Schließen keine messbaren Performance-Nachteile, aber das System läuft dann im konzipierten Modus.

&gt;Der Server ist mit 1 GB Speicher und zwei Prozessoren 1 GHz bestückt

Der MS SQL Server und MTS/COM+ "lieben" mehrere Prozessoren - daher ist dieses System ideal

[Gregor Bartosinski]

Herr Kosch vielne Dank für Ihre Antwort.

Aber kann ich mit dieser Komponente genauso mit methoden .edit und .post. Oder muß ich die Änderung mit update .. bzw. insert in die Datenbank einpflegen ?

Gruß Bart

[Andreas Kosch]

Hallo,

&gt;Aber kann ich mit dieser Komponente genauso mit methoden .edit und .post...

ja - sowohl bei TADOTable als auch bei TADODataSet macht im Hintergrund das <b>Recordset</b>-Objekt von ADO die ganze Arbeit. Die ADO Express-Komponenten sind nur die hübsche Umverpackung (damit wir via TDataSource die bequemen TDBEdit/TDBGrid anflanschen können). Allerdings ist nur TADODataSet speziell an das Recordset-Objekt angepasst, während bei TADOTable das möglichst gleiche Verhalten wie bei der BDE im Vordergrund steht. Dummerweise liegen zwischen ADO und der BDE sowohl von der Architektur her als auch vom Verhalten im Einzelfall aus betrachtet Welten, so dass die Simulation von TADOTable in der Regel nicht zu erfreulichen Ergebnissen führt

[Gregor Bartosinski]

Hallo Herr Koschnun

Nunhabe ich die Komponnente ersetzt.

Jetzt habe ich einProblem mit Table.ApplyUpdates . Die Funktion liefert einen Fehler so daß bei

if Table.ApplyUpdates(0) = 0 then
.........

ich keine Chance habe die Datenmenge zurück zu schreiben.
Wie kann ich feststellen warum dieser Schreibfehler zustande kommt?

Schönes Wochenende Gruß Bart

[Andreas Kosch]

Hallo,

&gt;Jetzt habe ich einProblem mit Table.ApplyUpdates ...

geht es hier immer noch um ADO? Die Methode ApplyUpdates kommt dort nicht vor, die gehört in den MIDAS-Bereich (DataSnap). In MIDAS wird über die Objektgalerie der vorgefertigte <b>Reconcile-Fehlerdialog</b> dem eigenen Projekt hinzugefügt. Damit das Formular im Fehlerfall auch wirklich in Erscheinung tritt, muss dazu eine Ereignisbehandlungsmethode für das <b>OnReconcileError</b>-Ereignis eingerichtet werden. Die dort aufgerufene globale Funktion <b>HandleReconcileError</b> wird im Reconcile-Fehlerbehandlungsformular deklariert und implementiert. Das könnte bei einem Beispiel so aussehen:
<pre>
uses CDS_EditReconcileReconcileFrm;

{$R *.DFM}

procedure TDataModuleCDS.ClientDataSetCountryReconcileError(
DataSet: TClientDataSet; E: EReconcileError; UpdateKind: TUpdateKind;
var Action: TReconcileAction);
begin
Action := HandleReconcileError(Dataset, UpdateKind, E);
end;
</pre>
Oder ist der Cachup Update-Mechanismus von TTable gemeint

[Gregor Bartosinski]

Guten Morgen Herr Kosch ,

jetzt wird interesant. Wenn man erst Erfahrung sammlen muß...
Aber ich möchte die geänderte Datenmenge einfach nur zurückschreiben . Benutze ich nur .post so reicht das bekanntlich nicht aus. Mit der Funktion ApplyUpdates (..) sollen die Daten doch an Server geschickt werden. Oder habe ich das falsch verstanden.

Oder gibt es einen anderen Weg wie die geänderten Daten an den Server geschrieben werden . Wohl gemerkt mit der ADODataSet-Komponente

Gruß Bart

[Gregor Bartosinski]

Hallo Herr Kosch,

ich bedanke mich für Ihre Mühe. Die letzte Anfrage habe ich selbst gelöst.

Gruß Bart