Umstellung ADO -> DBExpress

[ToFaceTeKilla]

Hiho,

So, zwar gleiches Thema, aber andere Fragen:
Wie ich hier schrieb, planen wir von ADO auf DBX umzusteigen.
Da wir nur unidirektional auf die Daten zugreifen, sehe ich darin erstmal kein Problem.
Wir benutzen hauptsächlich TADODataSet und TADOCommand. Ist es möglich diese ohne weiteres auf TSQLDataset bzw. TSQLQuery umzustellen? D.h. ist TSQLQuery überhaupt das Pandon zu TADOCommand?
Gibt es evtl. generelle Unterschiede in der Datenbehandlung, z.B. im Hinblick auf NULL, Datumswerte, Booleanwerte, etc.?

Vielen Dank schonmal

[Bernhard Geyer]

Wenn du nur auf MS SQL Server zugreifst bleib bei ADO. Ist der native Zugriffsweg. dbExpess verkompliziert hier nur den Zugriff.

[ToFaceTeKilla]

Naja, wir reden hier aber von einem Unterschied von 10 Minuten (ADO) zu 4 Sekunden (DBX) bei ein und derselben Abfrage. Das ist schon erheblich.
Es sei denn du kannst mir verraten, wie man ADO zu einer solcher Geschwindigkeit kriegt. Ich hab schon ein bisschen rumprobiert, z.B. CursoLocation auf clUseServer gesetzt, wodurch ich die Performance zwar verbessern konnte, was aber an anderer Stelle wieder zu Fehlern geführt hat, weil auf einmal RecordSets leer waren (die definitv nicht leer sein können). Im Großen und Ganzen weis ich aber nicht, was man da noch alles wie rauskitzeln kann.
Der Zugriff auf die Daten erfolgt im Prinzip wie folgt (beispielhaft):

Delphi-Quellcode:

procedure GetData;
var
  DataSet: TADODataSet;
begin
// Verbindung aufbauen
{...}
DataSet.Open;
while not DataSet.Eof do
begin
// Daten lokal in Objekten speichern
{...}
DataSet.next;
end

end;

Die Datenübertragung vom Server zum Client ist dabei (clUseClient) in wenigen Sekunden beendet. Das Iterieren durch das Dataset braucht dann ewig (~10min).
Gleicher Code nur mit TSQLDataSet (also DBX) ist in ca. 4 Sekunden erledigt.

Also wenn es da was zu verbessern gäbe, würde das auch reichen ;-)

[Bummi]

kenn' ich so gar nicht (so viele Daten ? / Blobs?), wobei serverseitige Cursor mit MSSQL-Server ohnehin problematisch sind. Hast Du schon mal:

Delphi-Quellcode:

 Adodataset1.LockType := ltBatchOptimistic;
 Adodataset1.Open;
 Adodataset1.Connection := nil;
 While not .....

versucht ?

[Bernhard Geyer]

Zitat:

Zitat von ToFaceTeKilla (Beitrag 1069951)

...Ich hab schon ein bisschen rumprobiert, z.B. CursoLocation auf clUseServer gesetzt, ...

Beim MS SQL Server sollte man möglich mit clUseClient arbeiten. Nur bei Anbindung an Grid wäre hier clUseServer besser.

Zitat:

Zitat von ToFaceTeKilla (Beitrag 1069951)

...stelle wieder zu Fehlern geführt hat, weil auf einmal RecordSets leer waren (die definitv nicht leer sein können).

Wir hier evtl. mit ExecuteOptions.eoAsyncExecute gearbeitet?

Zitat:

Zitat von ToFaceTeKilla (Beitrag 1069951)

Die Datenübertragung vom Server zum Client ist dabei (clUseClient) in wenigen Sekunden beendet. Das Iterieren durch das Dataset braucht dann ewig (~10min).

Sollte bei clUseClient kein Problem darstellen. [/QUOTE]

[ToFaceTeKilla]

Zitat:

Zitat von Bummi (Beitrag 1069955)

kenn' ich so gar nicht (so viele Daten ? / Blobs?), wobei serverseitige Cursor mit MSSQL-Server ohnehin problematisch sind. Hast Du schon mal:

Delphi-Quellcode:

 Adodataset1.LockType := ltBatchOptimistic;
 Adodataset1.Open;
 Adodataset1.Connection := nil;
 While not .....

versucht ?

Was kennst du so gar nicht?
Ich hab das jetzt mal mit verschiedenen LockTypes probiert. Ergebnis:
ltBatchOptimistic: 503 Sekunden
ltOptimistic (default): 508 Sekunden
ltReadOnly: 506 Sekunden
ltPessimistic 509 Sekunden

Die Werte liegen unter 10 Min. weil ich in dem Bsp. alles unnötige weggelassen habe (Anzeigeaktualisierung, Application.ProcessMessage...).
Macht also auch keinen unterschied.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1069957)

Beim MS SQL Server sollte man möglich mit clUseClient arbeiten. Nur bei Anbindung an Grid wäre hier clUseServer besser.

Ne mit Grids arbeiten wir nicht. Wir holen uns immer alle benötigten Daten ab und halten die im Speicher.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1069957)

Wir hier evtl. mit ExecuteOptions.eoAsyncExecute gearbeitet?

Nein. War beim Aufruf einer Stored Procedure.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1069957)

Sollte bei clUseClient kein Problem darstellen.

Bei clUseServer waren es dann aber (im nicht-optimierten Bsp.) nur noch 4 statt 10 Minuten. Und der Server entspricht von der Leistung her ungefähr meiner Workstation.

Edit: Zeit bei Readonly vergessen...
Edit2: ltPessimistic ergänzt

[Bernhard Geyer]

Hast du einen Profiler zur Hand? Unter D6 hatten wir performanceprobleme bei öffnen einer Dataset. War dann die bestimmung des Autoinc-Feldes. Evtl. gibts ja in D2010 auch ein Bottleneck bei ADO. Würde sich mit AQTime & Co. sehr schnell finden lassen.

[ToFaceTeKilla]

Ja, den im SQL Server Management Studio enthaltenen Profiler. Auf was muss ich den einstellen bzw. nach was suchen?

[Bernhard Geyer]

Nein, einen Profiler für den Pascal-Quellcode.

[ToFaceTeKilla]

OK, während ich (bisher erfolglos) mit ProDelphi rumgespielt habe, hat mein Kollege in der Zwischenzeit durch händisches Profiling (^^) die Lösung gefunden:

Delphi-Quellcode:

...
DataSet.DisableControls;
DataSet.Open;
...

bringt einen Performanceschub, sodass ADO die Aufgabe auch in 4 Sekunden erledigt. Und das obwohl wir keine Datencontrols benutzen. :gruebel:

Gut, dann wirds wohl bei ADO bleiben. :-)

Trotzdem danke ich euch, für die schnelle Hilfe :thumb: