TIBDataSet - Performance

[Bernhard Geyer]

Zitat von Hansa:

Zitat von Bernhard Geyer:

Bei Verwendung bei MySQL, Oracle und MySQL kann ich nur von sehr schönen Performance-Schub sprechen...

Sind das vielleicht die falschen DBs, also die, die man besser nicht verwendet ? 2-mal MySQL braucht sowieso keiner.

Muss sowieso noch einige Tables füllen und werde dafür prepare mal mitverwenden. Nur : wo soll das genau hin ? Vor das Open oder wohin ?

1 MySQL in MS SQL Server ändern

Vor das Open und jeweils in der Schleife nur Schließen, Paramterwerte ändern und öffnen.

[mkinzler]

Je nach FB-Version geschieht der Prepare automatisch

[Hansa]

1851 (fette) Datensätze werden aus Textdatei zeilenweise gelesen, zerstückelt, den DB-Feldern zugewiesen, in die DB gepostet usw. Zeit mit prepare : 56 Sek., ohne Prepare : 55 Sek. Die eine Sekunde ist bloß Zufall, weil ich mir nur ganze Sek. anzeigen lasse.

Nächster Versuch : SELECT * FROM TABLEX, also lesen der ganzen Tabelle mit allen Feldern. Ob mit oder ohne Prepare, es ist nicht gelungen dies in einer Zeit > 1 Sek. zu machen.

Zumindest bei FB ist das Prepare IMHO völlig überflüssig. Allerdings der Vollständigkeit halber noch folgendes für die Millisekunden-Jäger : bei wesentlich höherer Anzahl an Datensätzen oder z.B. wenn ich mir den Inhalt der erstellten Tabelle z.B. in einem Stringgrid anzeigen lasse, dauert es mindestens ca. 5-10 mal so lange alle Daten zu sehen, sofern das Memo/Grid usw. laufend aktualisiert wird. Kein Witz ! Die Windows Anzeige ist lahm wie die Sau. Sollen viele Daten angezeigt werden, dann habe ich mir angewöhnt, die später sichtbaren Sachen im Hintergrund zu bestücken und sie erst zu zeigen, wenn alles da ist. Für die User ist es schon ein Unterschied, ob sie 15 Sek. warten müssen, bis sie was sehen oder 1 Sek. Millisekunden sind denen allerdings völlig egal.

[Bernhard Geyer]

Zitat von Hansa:

1851 (fette) Datensätze werden aus Textdatei zeilenweise gelesen, zerstückelt, den DB-Feldern zugewiesen, in die DB gepostet usw. Zeit mit prepare : 56 Sek., ohne Prepare : 55 Sek. Die eine Sekunde ist bloß Zufall, weil ich mir nur ganze Sek. anzeigen lasse.

Dann zeig mal den relevanten Code mit Prepare/Parameterbestückung/Execute. Da ich bei "meinen" DB's mit Prepares + Paramter einiges heraushole denke ich mal das du hier was falsch machst (Reichenfolge).

[Hansa]

Das ist ja kaum was :

Delphi-Quellcode:

// Memo1.Lines.add (TimeToStr (time));
  DS.Prepare;
  DS.open;
  WHILE NOT Eof (t) DO BEGIN
    i := i + 1;
//    Memo1.Lines.Add(IntToStr (i));
    DS.Insert;
    NR := LeseIntFeld5;   // Nr. aus Textzeile lesen
    DS.FindField ('NR').AsInteger := NR;

Prepare wirkt sich nicht aus. Zumindest so nicht.

[Bernhard Geyer]

Scheinbar so nicht

Ich würde folgendes machen:

Delphi-Quellcode:

DS.SQL.Text := 'INSERT INTO <Table>(FeldListe] VALUES(:Param1, :Param2)';
DS.Prepare;

while ...
begin
  DS.SQL.Parameters['Param1'].AsString := ...;

  DS.Execute;
end;

[Hansa]

Bernhard, wie das SQL-Insert aussehen soll, das weiß ja schon das Dataset. Das brauche ich also nicht noch von Hand in den Source zu schreiben. Execute gibts da nicht. Was soll ich jetzt da machen ? Habe das Prepare jetzt an allen (un)möglichen Stellen eingesetzt. Es wirkt sich sich in keinster Weise aus.

[Bernhard Geyer]

Evtl. mußt du mit dem "normalen" SQL-Property arbeiten da bei verwendung von DataSet.SelectSQL/UpdateSQL/... die Komponente einfach nicht fähig ist die Statements preparen zu lassen. Gibts eigentlich bei Interbase/Firebird die möglichkeit auf DB-Seite die angekommenen Statements zu loggen?

[mkinzler]

Zitat:

Gibts eigentlich bei Interbase/Firebird die möglichkeit auf DB-Seite die angekommenen Statements zu loggen?

Momentan mit Boardmitteln nicht.

[Hansa]

Doch geht mit Bordmitteln (Trigger). Am besten benutzt man dazu aber IBExpert (wird allerdings wohl nur mit Vollversion gehen). Da werden die Log-Trigger und ein paar Log-Tabellen halbautomatisch angelegt (Grundgerüst). In einer DB habe ich zumindest aus Tests übriggebliebene IBE$LOG... irgendwas rumliegen.