der angehängte Fehler bringt mich noch um den Verstand.

Es handelt sich dabei um ein Delphi XE4 Programm und ab und zu ( nicht immer und nicht reproduzierbar ) tritt dieser Fehler auf.
Ich hab das Programm mit Debugs, Protokollen und Exceptions zugepflastert, aber ich kann nicht ermitteln bei was der Fehler auftritt.

Vor allem schaut das nach einem Speicherproblem aus. Der Müll am Ende des Cursornamens weist darauf hin.

Wir hatten das Problem damals schon in einer etwas anderen Form unter Delphi 6 Programmen.
Damals haben wir TIBQuery&Co geändert und den Namen des Cursors selber vergeben. Damit war das Problem aus der Welt.
Die Namen waren damals Random und mit einer sehr kurzen Nummer vergeben, diesen hatten wir verlängert.
Nachdem wir die Programm auf XE4 portiert haben, tritt das Problem erneut auf. Und diesmal können wir TIBQuery&Co nicht einfach ändern, weil Delphi dann beim kompilieren anmerkt das verschiedene DCUs mit unterschiedlichen Datum kompiliert sind.

Ich würde gern den Fehler verstehen, damit ich weiß wobei so etwas auftreten könnte.

So wie es aussieht, haben die IBX einen Fehler:
http://tracker.firebirdsql.org/browse/CORE-4559.

Keine leichte Aufgabe...

Frank

Hallo,

Zitat:

Keine leichte Aufgabe...

Wieso, die Lösung (IBX patchen) steht doch dort?
Ist nur sehr mühsam, das bei jeder Methode (Insert/Update/Delete) zu machen.

Wir hatten uns damals eine eigene TMyQuery abgeleitet und die entsprechenden Methoden überscheiben.
Und nein, die hieß nicht wirklich TMyQuery.

Der Rest ist dann Suchen/Ersetzen.

Moin,

danke für die Info.
Google wollte/will mir die Seite bei der Suche irgendwie nicht ausspucken.

dann schau ich mir das mal genauer an.

Gruß
Sven

Ich hoffe ich versteh das korrekt.

Wenn ich TIBSQL nutzen, dann füge ich den Code ein und nutze dann TMyIBSQL anstatt TIBSQL in meiner unit.
Da der FCursor Name im .create von TIBSQL generiert wird, sollte es reichen nach dem .create PatchIBSQLCursor aufzurufen.

also

markieren

Code:

q := TMyIBSQL.Create(nil);
q.database := dm.ibdb;
q.PatchIBSQLCursor(q);
.
.
.

Ausgabe in PatchIBSQLCursor vom Cursornamen schaut gut aus.

Korrekt verstanden?

In neueren Versionen (hier 10.2.3) wird der Cursorname überhaupt nicht mehr gesetzt, dort entfällt das Problem, da isc_dsql_set_cursor_name nicht aufgerufen wird.

Hallo,
nein, nicht korrekt verstanden.
Rufe die Patch-Methode im Constructor deiner abgeleiteten Klasse auf.

Somit ist der Patch immer automatisch gesetzt.

markieren

Delphi-Quellcode:

constructor TMyIBSQL.Create ...
begin
  inherited ....

  PatchIBSQLCursor(Self);
end;

Ok ja. Das spart natürlich Arbeit.

Zitat von Union:

In neueren Versionen (hier 10.2.3) wird der Cursorname überhaupt nicht mehr gesetzt, dort entfällt das Problem, da isc_dsql_set_cursor_name nicht aufgerufen wird.

In 10.1 wird es noch im .prepare von TIBSQL aufgerufen.

Ein Cursor wird bei IB/FB nur für einen wahrscheinlich seltenen Anwendungsfall benötigt. Nämlich nur dann, wenn man positioned Updates durchführen möchte, also Spalten im Lesepuffer beim Lesen sperren möchte.

Select ... for update of ... with lock

Zitat von API-Doc:

A cursor is a one-way pointer into the ordered set of rows retrieved by a statement. A
cursor is only needed to process positioned UPDATEand DELETEstatements made against
the rows retrieved by isc_dsql_fetch() for SELECT statements that specify an optional FOR
UPDATE OF clause.

Understanding the with lock clause