Bei vielen nicht korrekt abgeschlossenen Transkationen (z.b. killen des Prozesses beim Debgging) macht Firebird generell schwerste Probleme. Ich hatte gerade letzte Woche den Fall, dass ein Datenimport (640.000 Inserts mit 19 Feldern) anstelle von bisher 5 Minuten 6 Stunden benötigte.
Nach Backup + Restore war alles wieder schnell wie bisher.
Nicht FIrebird macht da schwerste Probleme, sondern wie fast immer derjenige, der an der Tastatur sitzt oder das Werkzeug, was der da benutzt.
Und ja, Transaktionen lange offen halten ist immer eine blöde idee, 5 minuten auf 6 Stunden bringen erfordert aber weit mehr als irgendwann
mal im debugging abgebrochen zu haben, wenn das problem an firebird liegen sollte. Und ich bin mir ziemlich sicher, das ein Blick in die MON$
Tabellen gezeigt hätten, welche Transaktionen da ggf. das Problem ausgelöst haben und ein ganz simpler delete from mon$attachment oder den
dienst neu starten hätte auch gereicht.
Was
ado oder die Komponente da veranstaltet oder warum bei euch der firebird so lahm ist, kann man per ferndiagnose natürlich schlecht sagen, aber ein weg das
zu beschleunigen ist eben wenn das mal auftritt beim Entwickler, einfach mal den Dienst neu starten, am besten aber vorher noch in mon$attachments
und mon$transactions reinschauen oder in ibexpert auf services-database monitoring in die gleichen bereichen (dort könnt ihr hängende
Transaktionen auch gleich beenden).
Und als weiterer Tip noch mal: prüft mal mit dem Benchmark wie schnell eure Maschine mit Firebird ist
und noch was, stell um auf parametrisierte queries (keine ahnung ob
ado commandtext das kann, wenn nicht, dann mach das besser gleich richtig und nehm native komponenten, mit denen das geht
//
sql wird außerhalb der schleife nur ein mal gesetzt
adoCommand1.commandText := 'insert into bla values (:p1, :p2, :p3);';
//falls es das gibt, mach ein prepare
adoCommand1.prepare;
Sw.Start;
for i := 0 to 2000 do
begin
//innerhalb der schleife dann nur noch parameter zuweisen
adoCommand1.parambyname('p1').AsInteger:=i+1;
adoCommand1.parambyname('p2').AsInteger:=i+2;
adoCommand1.parambyname('p3').AsInteger:=i+3;
adoCommand1.execute;
end;
Sw.Stop;
und wie schon gesagt, versuch nicht mit irgendwelchen ungeeigneten Komponenten überhaupt erst deinen Quelltext aufzubauen, die umstellung nachher auf performante Versionen lässt sich vermeiden, in dem man gar nicht erst mit ungeeignetem Kram anfängt.
Und wie schon gesagt, wenn du beispiele hier postest, ergänzen dein ddl und mach nicht irgendwelche umgestellten bla bla beispiele, oft sind kleine details der Grund, tabelle ohne indizes, ohne primary keys, dafür aber mit endlos triggerversuchen zB verlieren die zeit ganz woanders und nicht in dem Pseudo code.
ich stell die auswahl über
ado zu gehen grundsätzlich bei allen delphi versionen in frage, aber vielleicht siehst du dafür ja gründe (man könnte ja mal umstellen wollen auf andere plattformen ist keiner, dann nimm lieber firedac oder ibdac ...)