Delphi-PRAXiS
Seite 1 von 3  1 23      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Delphi FireBird - Too many Savepoints? (https://www.delphipraxis.net/119431-firebird-too-many-savepoints.html)

TUX_der_Pinguin 26. Aug 2008 14:33

Datenbank: FireBird • Version: 2.0.4 • Zugriff über: ZEOS 6.6.3 - stable

FireBird - Too many Savepoints?
 
Ich habe hier eine Anwendung, die sich beim Start mit einer embedded Firebird Datenbank Verbindet.
Beim Start der Anwendung wird ein Thread gestartet, der die Datenbank mit Daten füttert. Solange
der Anwendet nichts macht führt der Thread eine INSERT Anweisung nach der anderen aus.

Startet der Anwender eine Suche wo bei logischerweise eine Select Anweisung durchgeführt wird
so erhalte ich eine Exception: "gds internal Software consistency check... (Too many Savepoints (287))"
was soll das und wie verhindere ich diesen Fehler?

Ich bin ratlos und finde nichts bzw. nicht viel zu dem Thema.

mkinzler 26. Aug 2008 14:42

Re: FireBird - Too many Savepoints?
 
Wann erzeugst du Savepoints ( Teiltransaktionen)?

Hansa 26. Aug 2008 14:42

Re: FireBird - Too many Savepoints?
 
Und die Savepoints werden tatsächlich nicht von dir erstellt ? Ganz sicher nicht ? Zeos düfte die wohl sowieso nicht unterstützen (glaube das kann nicht mal IBX), oder doch ?

TUX_der_Pinguin 26. Aug 2008 14:55

Re: FireBird - Too many Savepoints?
 
Vor dieser Fehlermeldung habe ich nicht mals was von "Savepoints" gewußt,
ich arbeite nicht mit Transaktionen, das grobe Prinzip einer Transaktion
verstehe ich ja aber ich hatte das nicht für nötig gehalten das zu benutzen.

Also das hinzufügen von Datensätzen erfolgt vom Prinzip her so...
Delphi-Quellcode:
SQLQuery := TZQuery.Create(self);
SQLQuery.SQL.Text := 'INSERT INTO TAB (Kunde, Name) VALUES (:Kunde, :Name)';
SQLQuery.ParamByName('Kunde').asString := sKunde;
SQLQuery.ParamByName('Name').asString := sName;
SQLQuery.ExecSQL;
Das erledigt eine art "Update Thread" für mich im Hintergrund des Programms
im Vordergrund kann der Anwender in den Daten suchen dazu wird eine 'SELECT'
Abfrage erstellt und an die Datenbank geschickt, jedoch kommt dabei dann
die besagte Fehlermeldung.

Meine Vermutung ist das FireBird das nicht haben kann das man Datensätze hinzufügt
und gleichzeitig eine Select-Abfrage startet.

Da beim Programmstart die Datenbank ebenfalls befüllt wird, wenn diese leer ist
lasse ich meine Anwendung zu Testzwecken laufen und bisher ohne Probleme er hat
sicherlich schon so knapp 10.000 Datensätze hinzugefügt. Also an der Menge scheint
es nicht zu liegen, das war meine erste Vermutung das ich nicht ohne ende hinzufügen
kann ohne zwischen durch die DB zu "speichern".

Hansa 26. Aug 2008 15:18

Re: FireBird - Too many Savepoints?
 
Zitat:

Zitat von TUX_der_Pinguin
Vor dieser Fehlermeldung habe ich nicht mals was von "Savepoints" gewußt,
ich arbeite nicht mit Transaktionen, das grobe Prinzip einer Transaktion
verstehe ich ja aber ich hatte das nicht für nötig gehalten das zu benutzen...

Ersteres war zu erwarten. Und mit dem Verzicht auf Transaktionen hebelst du die ganze DB aus. FB ohne Transaktionen ? :shock: Dass dann irreführende Fehlermeldungen kommen, ist kein Wunder. Ein Select auf die gerade eingefügten Datensätze kann gar nicht gehen, bevor die betreffende Transaktion committed ist. Bzw. wird da nichts zurückkommen, weil das noch "inoffiziell" ist. Dass da jetzt irgendwas mit Savepoints angemahnt wird, das dürfte Zeos Schuld sein. :mrgreen:

mkinzler 26. Aug 2008 15:24

Re: FireBird - Too many Savepoints?
 
Zeos scheint wohl intern Savepoints zu verwenden. stelle auf explizite Transaktionssteuerung um

omata 26. Aug 2008 15:35

Re: FireBird - Too many Savepoints?
 
Ich hatte mal das selbe Problem.

Laufen deine INSERT-Statements in einem eigenen Thread ab? Also kann die Suchanfrage parallel dazu, natürlich nur über die selbe Connection, weil Embedded-Version, ausgeführt werden?

Dann musst du mit kritischen Abschnitten arbeiten und den Datenbankzugriff auch innerhalb deines Programms schützen.

TUX_der_Pinguin 27. Aug 2008 07:26

Re: FireBird - Too many Savepoints?
 
Zitat:

Zitat von omata
Ich hatte mal das selbe Problem.

Laufen deine INSERT-Statements in einem eigenen Thread ab? Also kann die Suchanfrage parallel dazu, natürlich nur über die selbe Connection, weil Embedded-Version, ausgeführt werden?

Dann musst du mit kritischen Abschnitten arbeiten und den Datenbankzugriff auch innerhalb deines Programms schützen.

Ja genau das Problem habe ich, was heißt den jetzt "kritische Abschnitte" ? Soll das heißen das ich bevor ich eine Suchanfrage
starte prüfen soll ob der Thread gerade dabei ist INSERT anweisungen auszuführen. Oder ist damit irgendwas spezielles gemeint?


Ansonsten kann ich ja auch wenn eine Suchanfrage gestartet wird das hinzufügen stoppen so das beim nächsten durchlauf
weiter gemacht wird.


Zitat:

Zitat von mkinzler
Zeos scheint wohl intern Savepoints zu verwenden. stelle auf explizite Transaktionssteuerung um

Was sind den diese Savepoints überhaupt und wozu sind diese gut, ich raff das noch nicht so ganz.

mkinzler 27. Aug 2008 08:19

Re: FireBird - Too many Savepoints?
 
Mit Hilfe von SavePoints kannst du Transaktionen in Teiltransaktionen zerlegen, welche du zurücksetzten kannst

TUX_der_Pinguin 27. Aug 2008 08:37

Re: FireBird - Too many Savepoints?
 
Ich habe das ganze jetzt wie "omata" vorgeschlagen gelößt und verhindere programm intern das Datenbank "Update" und Suche
zeitgleich ablaufen können, indem ich das "Update" abbreche wenn ein Suchvorgang gestartet wird, so bekommt der Anwender
nichts davon mit und die Fehlermeldung habe ich seit dem auch nicht wieder gesehen.

Zur Zeit kämpfe ich dafür an Performance problemen, ich beführchte das FireBird nie so flott sein kann/wird wie z.b.
ein Dedizierter MySQL Server aber das ist ein anderes Thema.


Alle Zeitangaben in WEZ +1. Es ist jetzt 07:11 Uhr.
Seite 1 von 3  1 23      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz