Excel ADO - geshwindigkeit ?

[myicq]

Ich muss per ADO Excel zugehen.
Ich benutze zzt folgendes, es geht, aber die Geschwindigkeit wird immer weniger als die Tabelle wächst.
Als ob ".Next" immer von vorne sucht ?


Die Ganze Tabelle muss in DbData[i,j] rein. DbData ist eine Array of Array of Widestring.

Delphi-Quellcode:

// for Excel and ODBC
// Number_Records = .RecordCount. 
// Headers_Count = number of fields / columns
// DbImportDB is a different form which has connection components.

begin
    for j := 1 to Number_Records - 1 do
    begin
            DBImportDB.DBTable.Next;   /// <<<< 
           for i := 0 to Headers.Count - 1 do
            begin
                  main.LogFile('Loading field ' + IntToStr(i), 4, TRUE);
                  if DBImportDB.DBTable.Fields.Fields[i]{FindField(Headers[i])}.Text <> '' then
                    DBData[i, j] := DBImportDB.DBTable.Fields.Fields[i].Value
                   else
                    DBData[i, j] := DBImportDB.DBTable.Fields.Fields[i].Text;
          end;
   end;    
end;

Für MS ACCESS benutze ich

Delphi-Quellcode:

    dbimportdb.DBTable.Recordset.MoveFirst;
    ....
       Recordset.MoveFirst;
        while not Recordset.eof do
             ....
        
            recordset.MoveNext;

Das ist mehrfach schneller, ABER Excel liest nur data aus 1. Reihe. Allerdings sovielmal wie RecordCount.


Ist "MoveNext" nicht für Excel erlaubt / möglich ?

Und geht es die ganze .UsedRange auf einmal zu lesen, statt Reihe für Reihe ?

[nahpets]

Keine Ahnung, wie es bei neueren Versionen von Delphi ist, aber bei ADO nutze ich immer sowas in der Art:

Delphi-Quellcode:

Table.First;
while not Table.EoF do begin
  Variabel := Table.FieldByName('Spaltenname'):AsString;
  Table.Next;
end;

Dabei ist es vollkommen egal, ob über den Connectionstring nun auf Access, Excel, FireBird oder sonst eine Datenbank verwiesen wird.

Der im Programm genutzte Quelltext ist immer gleich, für Excel ist keine Sonderbehandlung nötig.

Sprich: Deine schnelle Methode für Access sollte mit Excel ebenso funktionieren.

[mjustin]

Anstatt ADO kann man auch über ActiveX ein Excel-Dokument öffnen und dann komplette Bereiche in ein Variant-Array kopieren. ADO ist natürlich praktischer wenn man satzweise oder mit SQL arbeiten möchte, aber der ActiveX-Zugriff auf einige tausend Zeilen ist extrem schnell.

[haentschman]

Moin...:P

Frage:
Ist DBImportDB.DBTable ein TDataSet?

Dann könnte die Lösung folgendermaßen aussehen:
http://www.delphipraxis.net/192080-ado-langsam.html
Siehe Post #3, #15

[myicq]

Zitat:

Zitat von haentschman (Beitrag 1382118)

Moin...:P

Frage:
Ist DBImportDB.DBTable ein TDataSet?

Dann könnte die Lösung folgendermaßen aussehen:
http://www.delphipraxis.net/192080-ado-langsam.html
Siehe Post #3, #15

DANKE für die Hinweise! Werde ich demnächst probieren.

Ich glaube, wie im Post#3 vorgeschlagen, das ActiveX ohne Excel installiert zu haben, nicht möglich ist ? Ich werde auf dem Rechner gerade NICHT excel / Office zu verfügung haben. Nur MDAC. / ADO.

[myicq]

Zitat:

Zitat von haentschman (Beitrag 1382118)

Moin...:P

Frage:
Ist DBImportDB.DBTable ein TDataSet? (JA, ist es..)

Dann könnte die Lösung folgendermaßen aussehen:
http://www.delphipraxis.net/192080-ado-langsam.html
Siehe Post #3, #15

Das hat die Geschwindigkeit immens erhöht, bei 90.000 Records von etwa 1 Minute bis zu wenige Sekunden. DANKE! :thumb: