Firebird Import aus Textdatei extrem langsam

[omata]

Zitat von globetrotter77:

macht keinen Unterschied, jedenfalls nicht, was die Laufzeit angeht

...das ist klar, ist trotzdem der schönere und auch sicherere Weg.

Zitat von globetrotter77:

...aber ich muss die doppelten Schlüssel zumindest protokollieren, daher ist eine Einzelsatzbearbeitung leider erforderlich...

Wenn du die Daten erstmal in der Datenbank hast, ist die Prüfung auf doppelte Einträge doch super einfach. Das Protokollieren muss doch nicht unbedingt beim Einfügen geschehen. Dieser Weg ist doch viel flexibler und die Daten können dann leichter weiterverarbeitet werden.

[globetrotter77]

Zitat von omata:

Wenn du die Daten erstmal in der Datenbank hast, ist die Prüfung auf doppelte Einträge doch super einfach. Das Protokollieren muss doch nicht unbedingt beim Einfügen geschehen. Dieser Weg ist doch viel flexibler und die Daten können dann leichter weiterverarbeitet werden.

wieso ist das dann super einfach?
wie meinst du das?

[omata]

Wenn die Daten in der Datenbank sind, kannst du sie doch wesentlich einfacher per SQL formen, weiterverarbeiten und analysieren, als wenn du alles selber programmieren musst. Der Aufwand entfällt dann und du kannst alles über einfaches SQL lösen.

[omata]

So, ich habe das jetzt mal selber ausprobiert...

Code:

1.000.000   Zeilen = 0:18 (Datei = 16MB)
1.000.000.0 Zeilen = 2:48 (Datei = 166MB)

Also für einen Datensatz ca. 18µs (auf meiner Maschine = P4, 3GHz)

[mjustin]

Delphi-Quellcode:

        
        with DM_User.SQLQueryTemp do
        begin
          with SQL do
          begin
            Clear;
            Add(sqltxt);
          end;
          ExecSQL(true);
        end;

Ich würde die Query nur einmal zu Beginn des Einlesens erzeugen und den SQL-Text zuweisen, dabei dann mit Parametern arbeiten:
insert into tabelle(f1, f2, f3, ...) values (:f1, :f2, :f3, ...) In der Einleseschleife dann die Parameter zuweisen und ExecSQL aufrufen. Vorteil: die Query wird vom Server nur einmal erzeugt und dann für jedes Insert wiederverwendet. ("Prepared Statement").

Eventuell hilft es auch noch, die ganze Sache in einer Transaktion laufen zu lassen.

Viele Grüße,

[mkinzler]

Und eine explizite Transaktionssteuerung verwenden. Denn sonst wird dank autocommit jeder Insert insert in eine eigene Transkation gepackt.

[globetrotter77]

Zitat von mkinzler:

Und eine explizite Transaktionssteuerung verwenden. Denn sonst wird dank autocommit jeder Insert insert in eine eigene Transkation gepackt.

Aha! Das könnte natürlich ein Problem sein!
und wie macht man das mit der expliziten Transaktionssteuerung?

[mkinzler]

Mit dbExpress kenne ich mich nicht aus, aber versuche mal
SQLConnection.StartTransaction() und SQLConnection.Commit()

[globetrotter77]

StartTransaction erwartet einen "benutzerdefinierten Transaktionsbezeichner" - was ist denn damit gemeint??
und wie macht man das?

[globetrotter77]

Zitat von mjustin:

Ich würde die Query nur einmal zu Beginn des Einlesens erzeugen und den SQL-Text zuweisen, dabei dann mit Parametern arbeiten:
insert into tabelle(f1, f2, f3, ...) values (:f1, :f2, :f3, ...) In der Einleseschleife dann die Parameter zuweisen und ExecSQL aufrufen. Vorteil: die Query wird vom Server nur einmal erzeugt und dann für jedes Insert wiederverwendet. ("Prepared Statement").

Bin schon ganz meschugge ...
wie war das nochmal mit den Params?
wie ordne ich denen Werte zu?
geht das mit
SQLQuery.Params[0].Value:='blabla'; und muss ich das Prepare selbst auslösen?