ADODataSet indizieren

[Tobias Frost]

Hi,

ich muß die Records einer MS SQL-Server Tabelle modifizieren (ca. 30000); Dazu lade ich die Datensätze in ein TBetterADODataSet das im BatchOptimistic-LockType geöffnet ist. Der Cursor muß per Locate positioniert werden, was unverhältnismäßig langsam geht. Daher mein Versuch die Tabelle einfach temporär zu indizieren was mit der Meldung fehl schlug, daß der OLE DB-Provider keine Index-Funktionalität zur Verfügung stellt !!!?

Ich habe den MS SQL-Server 2000 installiert, nutze D6 auf einem ausreichend dimensionierten PC unter W2000.

Hat jemand eine Idee, was da falsch läuft, wenn überhaupt ?

Tobias

[hwoess]

Hallo Tobias,

schon voll im Einsatz, was? Wie ich sehe, hast du dich für ADO entschieden. Habe dir auf die Frage bezüglich Direktzugriffskomponenten noch was dazugeschrieben - schon gesehen?

Jetzt zu dem Riesenupdate. Warum werden da alle 30000 Records auf einmal geladen? Ich würde das Record für Record mit einer Query machen und statt Locate bei geeignetem Index immer auf die Datenbank zugreifen. Schneller wird's dann noch, wenn man die Transaktion selber steuert und nicht nach jedem Update ein Commit macht sondern vielleicht nur nach jedem 1000sten. Weiters Querys mit Parameter verwenden und vorher ein Prepare. Und dann noch wo möglich Locktype auf ReadOnly setzen ...

Aber vielleicht geht es auch mit einer stored proc, da wäre dann die Hauptlast direkt am Server in der DB - schneller gehts dann meist nicht mehr, vorausgesetzt die SQL Statements stimmen und die Indizes passen.

bye,
Helmut

ach ja, das mit dem Index-Error stimmt! Es gibt da keine Indizes auf Tabellen, habe schon mal gelesen, warum das so ist, aber leider wieder vergessen

[Tobias Frost]

Hi Helmut,

mir geht es speziell um die Batch-Fähigkeit der ADO-Komponente. Es handelt sich um ein tägliches Update in dem sehr viel gerechnet wird - Umsatzdaten für die Controlling-Abteilung. Da die noch unveränderten Daten weiter im paralellen Zugriff bleiben müssen, soll die Transactions-Zeit so kurz wie möglich sein. Daher laden, bearbeiten, wegschreiben. Das Prinzip findet schon meine Zustimmung, nur ein Locate ohne Index ist definitv zu langsam. Bin etwas verwundert, warum es das nicht geben soll ... Ich habe die Funktionalität inzwischen serverseitig realisiert - TSQL bietet bis jetzt weniger als es verspricht ...

Ich habe die SDAC-Komponenten von Corelab kurz installiert und knapp begutachtet. Leider fehlt die Zeit, um alle Komponenten zu testen und so bleibt ADO vorerst die Qual der Wahl. Schon auf Grund der dafür vorhandenen Literatur ...

Wo mag das mit dem Index-Error den wohl gestanden haben ?

Gruß, Tobia

[Andreas Kosch]

Hallo,

an dieser Stelle erhält der Falsche die "Prügel". Das native Recordset von ADO stellt keine Methode <b>Locate</b> zur Verfügung, sondern dieses Teil stammt von Borland.

Die folgenden Auszüge stammen aus meinem Buch <i>ADO und Delphi</i>:

Die ADO Express-Komponenten wie zum Beispiel TADODataSet (und somit auch der Nachfolger TBetterADODataSet) stellen die Methode Locate zur Verfügung, um einen Datensatz in der Datenmenge aufzuspüren. Hinter dieser Methode steckt ausnahmsweise keine Interface-Methode des Recordset-Objekts, sondern die Methode Locate setzt intern je nach vorgefundener Situation auf die Recordset-Methode <b>Find</b> oder die Recordset-Eigenschaft <b>Filter</b> auf. Der Vorteil von Locate liegt für uns insbesondere darin, dass wir mit ADO Express über den von der BDE her gewohnten Weg suchen können. Allerdings ist dieser Weg niemals der schnellste Weg :-)

Das native Recordset-Objekt stellt die Methode <b>Sort</b> zur Verfügung, um die Ergebnismenge im Recordset nach eine "virtuellen Indexspalte" zu sortieren.

Das Recordset-Objekt stellt die Methode <b>Find</b> zur Verfügung, um einen bestimmten Datensatz in der Ergebnismenge lokalisieren zu können. Diese Methode steht bei client-seitigen Cursors (clUseClient) immer zur Verfügung und bei den serverseitigen Cursors nur dann, wenn die restlichen Konfigurationen die Unterstützung von Bookmarks erlauben. Immer dann, wenn Find bei clientseitigen Cursorn aufgerufen wird, erzeugt ADO über die OLE DB Client Cursor Engine einen <b>internen Index für das Feld</b>, das in dem Suchbegriff referenziert wird. Aus diesem Grund bietet die Methode Find auch die Option an, als zweiten Parameter die Anzahl der zu überspringenden Datensätze zu übergeben, so dass die erneute Suche erst nach dieser Datensatzposition gestartet wird.

<pre>

<b>procedure</b> TForm1.ButtonFindClick(Sender: TObject);
<b>begin</b>
FRSFind := ADODataSet1.Recordset;
FRSFind.Find(Format(<font color="#9933CC">'City = %s'</font>, [QuotedStr(EditLocate.Text)]),
0, adSearchForward, EmptyParam);
ADODataSet1.Resync([rmExact]);
<b>end</b>;

<b>procedure</b> TForm1.ButtonFindNextClick(Sender: TObject);
<b>begin</b>
FRSFind.Find(Format(<font color="#9933CC">'City = %s'</font>, [QuotedStr(EditLocate.Text)]),
1, adSearchForward, EmptyParam);
<b>if</b> FRSFind.EOF <b>then</b> <b>begin</b>
ShowMessage(<font color="#9933CC">'Keine weiteren Fundstellen'</font>);
FRSFind.MoveFirst;
<b>end</b>;
ADODataSet1.Resync([rmExact]);
<b>end</b>;

</pre&gt