Hi IBExpert.
Die von Dir beschriebenen 'best practices' sind sehr interessant, ein kleines Beispiel wäre allerdings noch besser, vor allen Dingen
Zitat von
IBExpert:
Zitat von
alzaimar:
Noch heine Anekdote:
Hängt mehr oder weniger mit der Auflösungsreihenfolge zusammen.
ich habe die joins auch umsortiert, brachte keinen Erfolg.
Die
Query, die einen offensichtlichen Bug von Firebird zeigt, liefert genau dann korrekte Ergebnisse, wenn ein bestimmtes Feld der VIEW (das ich gar nicht benötige) mit in die Auswahl genommen wird.
Die
DB hat 300MB, ich könnte sie dir per RAR zukommen lassen, wenn Du magst (schick mal ne Mail-Adresse per PN). Ich möchte scheinbar unbeteiligte Daten nicht entfernen, da dies zu Seiteneffekten führen könnte, die den Bug wieder unsichtbar machen.
Mittlerweile hat sich mein 'Ärger' auch etwas gelegt, denn die
DB (nicht von mir) war mit kaskadierenden DELETE-Triggern übersäht, z.T. auch noch quasi rekursiv (DELETE-Trigger auf Tabelle A löscht aus B und der DELETE-Trigger von B löscht in A, toll).
Mittlerweile scheint Firebird doch nicht so langsam, zumindest was DELETE und INSERT anbelangt, zumindest ist mein Kaffeekonsum nun wieder auf 'normal'.
Ärgerlich ist derzeit nur noch, das
FB bei offenen Transaktionen immer langsamer wird. Ich habe eine Anwendung 'A', die irgendwo eine offene Transaktion hat. Ich bin mir fast sicher, das es nur eine offene
Query (DBExpress) ist. Na jedenfalls wird Anwendung 'B', die in die Datenbank schreibt, immer langsamer. Das nervt. Ist aber vermutlich genauso eine Gehirnabsenkung des
DB-Erstellers. Irgendwo.