MSSQL server + ADO = lahme Ente ????

[generic]

Wenn du das Borland ADO nimmt, ja das ist bekanntlich nicht das schnellst.
Native Ado geht erheblich schneller.

Andreas Kosch hat sich schon einige mal in seinen Büchern drüber ausgelassen.
Wobei eure Datenanzahl noch nicht besonders hoch ist.

Evtl. der SQL Server nicht optimal Eingerichtet?
Zu wenig Ram? Logfiles auf langsamen Platten?
Keine/Falsche Indizes/Statistiken?

SQL-Profiler laufen lassen um den Engpass ermitteln.

[Bernhard Geyer]

Zitat von generic:

Wenn du das Borland ADO nimmt, ja das ist bekanntlich nicht das schnellst.
Native Ado geht erheblich schneller.

Ist mir bisher eigentlich nur aufgefallen beim öffnen von vielen Recordsets mit wenige Ergebnisdatensätzen.
Dort wird immer versuch zu erkennen ob autoinc-Felder beteiligt sind.

Zitat von generic:

Evtl. der SQL Server nicht optimal Eingerichtet?
Zu wenig Ram? Logfiles auf langsamen Platten?
Keine/Falsche Indizes/Statistiken?

SQL-Profiler laufen lassen um den Engpass ermitteln.

Es gibt einiges wo man drehen könnte. Curserlocation wäre z.B. eine Option.

[bernhard_LA]

unter DELPHI XE2 haben dbgo (ADO) eingebaut, wenn wir uns die 400K Datensatze in einer query vom Server holen dauert dies ca. 10 min, das Durchlesen dann in einer Schleife mit TQuery.NEXT die besagenten 2 Stunden

[Bernhard Geyer]

Zitat von bernhard_LA:

unter DELPHI XE2 haben dbgo (ADO) eingebaut, wenn wir uns die 400K Datensatze in einer query vom Server holen dauert dies ca. 10 min, das Durchlesen dann in einer Schleife mit TQuery.NEXT die besagenten 2 Stunden

Stell mal Curserlocation auf clUseClient ein.

[Furtbichler]

Zitat von bernhard_LA:

das Durchlesen dann in einer Schleife mit TQuery.NEXT die besagenten 2 Stunden

1. Was macht die Schleife?
2. Verwendest Du "FieldByName", oder "DataSet['MyField']"?
3. Hast Du ein Grid angeschlossen oder andere datensensitive Elemente, TDBEdit o.ä.?
3. Eine ADO- oder was weiss ich- Tabelle ist nicht ideal, um über viele Datensätze zu iterieren.

Ich bin immer noch der Überzeugung, das Du mit einer Query bzw. eine UDF oder SP schneller zum Ziel kommst.

[p80286]

Zitat von bernhard_LA:

unter DELPHI XE2 haben dbgo (ADO) eingebaut, wenn wir uns die 400K Datensatze in einer query vom Server holen dauert dies ca. 10 min, das Durchlesen dann in einer Schleife mit TQuery.NEXT die besagenten 2 Stunden

Ich glaube da gibt es ein Mißverständnis. Nach dem "Open" trudelt der erste Datensatz ein.
Das ist ein Verhalten was ich auch bei anderen DBs beobachte, das Datenschieben über's Netz dauert. Du solltest ggf. mal die Datenmenge überprüfen.

Gruß
K-H

[Bernhard Geyer]

Zitat von p80286:

Ich glaube da gibt es ein Mißverständnis. Nach dem "Open" trudelt der erste Datensatz ein.
Das ist ein Verhalten was ich auch bei anderen DBs beobachte, das Datenschieben über's Netz dauert. Du solltest ggf. mal die Datenmenge überprüfen.

Trotzdem Stichwort CurserLocation:

clUseServer: Datensätze werden erst gefetcht wenn sie benötigt werden - Hohe serverbelastung
clUseClient: Mit dem öffnen werden alle Ergebnisdatensätze sofort um Client übertragen. währen der Durchiteration müssen diese nicht erst "Zeitaufwändig" immer wieder angefragt werden.

Solltest du die Datensätze nur zum exportieren (ohne Rückwärts-Positionierung) benötigen wäre auch ein Forward-Only-Curser sinnvoll.

[bernhard_LA]

wir haben eine TQuery mit 400K Elementen in der Ergebnismenge und eine Schleife

Delphi-Quellcode:

    


    Query.first

    
    Query.Next

      Zugiff auf die einzelnen Werte mit 
  
       Query.FieldByname( .....)


    until query.EOF

ist FieldbyName die Performance Bremse ?

[p80286]

Sollte man meinen, aber lt Hilfe ist dies nicht der Fall. Aus irgendwelchengründen ist das iterieren durch die Felder etwas langsamer.
Wie schon mehrmals angesprechen überprüf einmal die Cursor.
Je nachdem welche Datenbank im Hintergrund werkelt hat das einige Auswirkungen auf Geschw./Speicherverbrauch.

Gruß
K-H

[Iwo Asnet]

FieldByName sucht jedesmal in der Feldliste nach dem Feld mit dem Namen...

Führe die Analyse im Server aus oder schreibe dir eine extended stored procedure. Wenn das Resultat keine Riesenmengen sind, ist das in jedem Fall die bessere Wahl.