ADO Langsamer als BDE?

[Jenns]

Hallo,

ich möchte mein Programm in Delphi 7 von Paradoxtabellen auf einen SQL Server umstellen.

Jetzt habe ich im ersten Schritt einfach die Table auf den neuen Server gelenkt, indem ich unter ODBC eine Verbindung mit dem SQL Native Client eingerichtet habe.
Das geht ungefähr gleich schnell.

Im zweiten Schritt will ich jetzt die Table durch ADOTable ersetzen.
Hierbei stelle ich fest, das öffnen der Tabelle über ADOTable 100x so lange dauert wie über den BDE-Table.

Sprich das active setzen einer Tabelle mit 80.000 Datensätzen dauert
mit BDE auf Paradox ca. 20 ms,
mit BDE auf SQL ca. 20 ms,
mit ADO über ODBC auf SQL ca. 2000 ms und
mit ADO über SQL Native Client auch ca. 2000 ms.

Gemessen habe ich das mit QueryPerformanceCounter(); und die Werte geben auch ungefähr mein persönliches Empfinden wieder.

Der connectionstring bei Ado ist:
adotable1.ConnectionString := 'Provider=MSDASQL.1;Password=xxx;Persist Security Info=True;User ID=xxx;Data Source=SQLServer;Initial Catalog=Datenbank';
bzw.
adotable1.ConnectionString := 'Provider=SQLNCLI.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=Dtenbank;Data Source=mein-pc\sqlexpress';

Die Cursorlocation steht auf clUseServer, mit clUseClient sind die Werte noch schlechter.

Was mache ich falsch? Müssen noch andere Einstellungen gemacht werden?

Gruß, Jenns

[nahpets]

Hallo,

habe es noch nie nachgemessen, aber ADO fühlt sich langsamer als die BDE an. Zumindest bei SQL-Server und Oracle hatte ich schon diesen Eindruck.

[hoika]

Hallo,

Zitat:

Jetzt habe ich im ersten Schritt einfach die Table auf den neuen Server gelenkt, indem ich unter ODBC eine Verbindung mit dem SQL Native Client eingerichtet habe.

So einfach ist es nicht.
Du bist von Paradox auf SQL-Server umgestiegen.
Das ist ein Riesenunterschied.

Was du mit dem ODBC willst, weiss ich nicht.
Lass das ODBC weg.

SQL-Server -> ODBC -> ADO -> TAdoTable

Einfach TTable durch TAdoTable zu ersetzen, reicht nicht aus.
Eine AdoTable versucht ja, das TTable komplett zu ersetzen.
Dazu gehören Infos wie Felder, Indizes (IndexDefs) usw..
Das ist zwar schön, aber ein grosser Overhead.
Nutzung der AdoTable nur bei kleinen Tabellen
und auch während des Umstiegs von Pdx.
Später sollte das ersetzt werden.

Das muss ein AdoTable beim Open erst mal alle Tabellen-Infos vom Server holen,
es werden dazu mehrere Queries verwendet.
Unter Pdx standen die Infos direkt im Header der Tabelle,
standen nach dem Open also direkt zur Verfügung.

Ausserdem wird ein Select * From Table ausgeführt,
egal was du mit der Tabelle vorhast.
Das ist dann meistens auch das Performance-Problem.

Lege mal eine leere Tabelle auf dem Server an,
und öffne die. Das sollte schneller gehen als eine volle Tabelle.


Fazit:
Nutze TAdoQuery, besser aber TAdoDataSet.
Das heisst aber leider auch "ein bisschen" Neuprogrammierung.

Meistens sind TTable unter Pdx schneller,
TQuery/TAdoDataSet unter SQL-Server.

Und bevor jemand meckert, ich sagte "meistens" ;)


BTW:
Ich habe eine grosse Anwendung von Pdx auf Firebird umgestellt,
und weiss über Performance-Probleme leider nur allzu gut Bescheid.



Heiko

[QuickAndDirty]

Die BDE war schon immer für Zugriffe auf kleine Datenschnipsel das schnellste wo geht.

Vor allem wird der TABLE Zugriff von der BDE sehr sehr gut unterstützt.

Table Zugriffe mit der BDE auf GROße remote SQL Tabellen sind dafür ein KRAMPF
und da fängt groß schon ab weit unter einem MB an.

ADO ist doch soweit ich weiß eine COM Objekt Geschichte...die sind doch schon per Definition nicht die Performance Monster.


Ich weiß nur das bisher an Geschwindigkeit die BDE LOKAL unschlagbar ist...wenn man all die Probleme kennt die zu berücksichtigen sind...damit es wirklich schön schnell läuft....
In Sachen DatenUNsicherheit im Netzwerk sind sie dafür die Größten!!!
Dann kommt noch die Virenscanner Geschichte im Netz dazu und das Geficke mit den ADIMNS die Dateifreigaben mit Vollzugriff einrichten müssen....und sich in den Domaincontrolern nicht zurecht finden.

[mkinzler]

Wenn man eine Projekt von BDE 1:1 auf einen SQLServer umstellt wird man u.U. einen großen Performanceverlust feststellen. Wenn man das Programm aber richtig umstellt, besteht die Möglichkeit performanter zu sein.

[QuickAndDirty]

Nicht bei einer Einzelplatzlösung,


Performance kann man aus nem SQL Server eigentlich nur mit Stored Procedures bekommen...
das macht meist auch nur bei einer Mehrplatzlösung Sinn.

[hoika]

Hallo,

Einspruch Eurer Ehren ... ;)

Schon simples Grouping, Count usw.
ist mit nem SQL-Server u.U. schneller erledigt als per BDE.

Dass kommt aber auch auf die Datenmenge an.

Aber es stimmt schon, da ja lokal gecacht wird (seitens der BDE und des Dateisystems),
ist die BDE lokal schnell.
Allerdings öffnet ein Table.Open bei Pdx aber
alle Dateien (db, px, Indizes).
Das kann auch lokal etwas dauern.


Im Netz relativiert sich das aber wieder.


Heiko

[Bernhard Geyer]

Also wir haben früher auch mit BDE auf SQL Server zugegriffen. Nach Wechsel auf ADO (für MS SQL) und native Komponenten für MySQL und Oracle war der Zugriff etwas langsamer. Jedoch haben wir mittlerweile über gecachte preprared Statements die Geschwindigkeit der BDE weit hinter uns gelassen. Und ohne BDE sind die Supportaufwände (Zeiten, Nervern) fast gegen 0 gegangen.