Interbase record key deleted

[Helmut F. Zmaritsch]

Hallo,

wer weiß Rat ?

Ich habe einen Effekt den ich mir nicht mehr erklären kann.

Equipment: NT 4.0, Delphi 4, Interbase 5.1.1

Es wird über eine TTable-Komponente per "Table.Insert" und "Table.Post" ein Datensatz in die Datei (lokal auf Rechner) geschrieben.

Der Satz wird korrekt gespeichert, es erfolgt von der BDE dennoch die Exception "DBEngine Error - record key deleted".

Die eindeutige ID (Integer) des Datensatzes wird "vor dem Posten" im Ereignis OnNewRecord gebildet. Diese wird mittels einer Stored Procedure (Auslesen eines Generators) ermittelt.

Die Literatur besagt, daß die BDE von Delphi unmittelbar nach dem Posten den Satz zur Kontrolle noch einmal einliest. Falls sie diesen vom Server nicht zurückerhält, wird die Meldung "record key deleted" abgesetzt.

Die Meldung tritt mit Recht auf, falls ein Trigger in der Datenbank die ID geändert hat und die BDE davon nichts weiß, daher auch der Satz richtigerweise nicht zurückgegeben wird.

In meinem Fall wird jedoch die ID bereits vor dem Posten eingesetzt, so daß der Trigger nicht feuert (wird kontrolliert, da dieser testweise die Meldung "fired" ausgibt).
Der Datensatz wird unter Zuhilfename der BDE vollständig ausgefüllt geposted. Genau so wird er auch gespeichert und kann gelesen werden.
Trotzdem meldet die BDE "record key deleted"

Die Profis sind gefragt - ich finde keine Erklärung mehr.

Grüsse
Helmut

[Andreas Tengicki]

<p> Auch ich kann mir den Effekt ohne weitere Tests nicht erklären, verweise aber nochmals darauf das der Einsatz von TTable und SQL-Datenbanken (wie InterBase) sich widerspricht. TQuery <b> muss </b> das Mittel der Wahl sein </p&gt

[Kai Möller]

Hallo,

das kann ich nach eigenen Erfahrungen ebenfalls nur dringend raten:
Ich habe mal mit einer TTable (an Interbase 5.5) Updates in einer Schleife gemacht (der Key war vom Update gar nicht betroffen!).
Ganz unmotiviert kam oft nach ein paar hundert Updates die berüchtigte Meldung 'Datensatz/Schlüssel gelöscht'. Da half auch kein Probieren mit den Eigenschaften UpdateMode, etc...

Auf die Table-Komponente habe ich nicht verzichtet, schicke die Updates jedoch jetzt über eine extra TQuery zum Server. Die Fehlermeldung verschwand und ich wurde zusätzlich durch wesenltich bessere Performance belohnt.

Gruß Kai

[Andreas Kosch]

Hallo,

handelt es sich beim Primärschlüssel (eindeutige ID) um grosse INTEGER-Werte (> 1000000)? Wenn ja, sollte der Versuch einmal mit sehr kleinen INTEGER-Werten wiederholt werden. Verschwindet dann die Fehlermeldung, liegt vermutlich eine "falsche" MSVCRT.DLL auf dem Rechner (Borland, Microsoft und auch andere Softwarefirmen haben vor einige Monaten eine Warnung verschickt, das durch eine der <i>Microsoft Visual C</i> Runtime-DLLs die INTEGER-Darstellung zur Laufzeit auf die wissenschaftliche Notation (z.Bsp: 5,12121E4) wechselt. Und diese Zahl wird dann nicht in der Datenbank gefunden.

Um diese Fehlerursache auszuschliessen, sollte der Test ausserdem mit fest zugewiesenen INTEGER-Werten wiederholt werden (d.h. das Erebnis der Stored Procedure wird ignoriert). Wenn das erfolgreich war, würde ich mir das Ergebnis der Stored Procedure etwas genauer ansehen - wie sieht diese Zahl aus?

P.S. Das C/S-System <i>Centura SQLWindows/32</i> ist zum Beispiel ebenfalls von diesem Fehler betroffen. Allerdings ist mir das mit Delphi+Interbase noch nie untergekommen (die Borland-Warnung bezog sich auf den ORACLE-Treiber der BDE).
&#10

[Kai Möller]

Hallo Andreas,

also in meinem Fall hat die betroffene Tabelle einen zusammengesetzten Key aus zwei Spalten des Typs Varchar. Es muß also noch eine andere Ursache für den Fehler geben.

Gruß Kai

[Helmut F. Zmaritsch]

<p>Hallo Herr Kosch!</b>

Es wird durch die Stored Procedure eine Integerzahl erzeugt, da der Satz ja nachher gelesen werden kann und dort die Zahl ersichtlich ist.

Die Meldung "record key deleted" der BDE ist also sehr mysteriös.

Übrigens tritt die Fehlermeldung "bei jedem Speichern" auf.

Ich verwende jetzt ersatzweise eine Methode über eine SQL-Query. Hier habe ich aber (ohne einen expliziten Lesevorgang) keine Kontrolle, ob der Satz tatsächlich in die Datenbank eingefügt wurde, oder doch ?

Übrigens, meine Großmutter väterlicherseits hat mit ihrem Mädchennamen auch Kosch (Rosina) geheißen. Vielleicht sind wir sogar weitschichtig miteinander verwandt ?

Gruss aus Wien, Helmu

[Andreas Tengicki]

---
Ich verwende jetzt ersatzweise eine Methode über eine SQL-Query. Hier habe ich aber (ohne einen expliziten Lesevorgang) keine Kontrolle, ob der Satz tatsächlich in die Datenbank eingefügt wurde, oder doch ?
---

Wenn das ausführen des SQL Statements (bzw das Post bei Request Live = True) erfolgreich war, können sie davon ausgehen das die Daten in der Datenbank sind.

(auf irgendwas muß man sich ja verlassen