Firebird 2.5 Generator falsch - Trigger FireDAC

[Emwykey]

Sorry ich schreib das hier nebenher...

nochmal ausführlich vielleicht:

Es gibt keinen Insert auf die Archiv Tabelle im Code - Ausschließlich über den Trigger auf der Tabelle selbst.

Für eine unvorhersehbare Zeit funktioniert alles prima, plötzlich steht der Generator auf einem alten Wert. Übersprungene Werte habe ich noch nicht gesehen, sind aber auch kein Problem.

Wenn ich den Generatorwert nun händisch korrigiere funktioniert es 1 mal, danach ist der Wert wieder falsch. -- Bei anderen Fällen ging es dann aber auch wieder für längere Zeit

Wenn ich vor oder nach der Korrektur ein Backup Restore durchführe tritt der Fehler nicht mehr auf ( zumindest für eine gewisse Zeit )

Der Generator wird Ausschließlich im Trigger angesprochen


Das selbe tritt auch bei anderen Tabellen auf, welche nur zum Teil durch den Trigger mit der ID versehen werden, ab und an wird der Generator auch direkt angesprochen ( daher die Abfrage auf ID is null)

Das ganze passiert in einigen Kopien der Datenbank, aber nicht in allen. Es passiert zu unterschiedlichen Aktionen Zeiten und bei unterschiedlichen Generatoren - ich konnte bisher noch keine Gemeinsamkeit entdecken.

Es gibt für den aktuellen Fall kein Element abgesehen von den Triggern welches auf Generator oder Tabelle Archiv zugreift


Danke nochmal für eure Mühen

[Lemmy]

Zitat von Emwykey:

Wenn ich den Generatorwert nun händisch korrigiere funktioniert es 1 mal, danach ist der Wert wieder falsch. -- Bei anderen Fällen ging es dann aber auch wieder für längere Zeit

Wenn ich vor oder nach der Korrektur ein Backup Restore durchführe tritt der Fehler nicht mehr auf ( zumindest für eine gewisse Zeit )

dann mach vor der nächsten Korrektur bitte mal ein gfix wie oben beschrieben - ich vermute, die DB hat da nen Schaden, der durchs Backup/restore gefixt wird.

[hoika]

Hallo,
vielleicht wird ja in einem Trigger, der nicht so häufig verwendet wird,
der falsche Generatorwert drin.
Exportiere mal deine DB (IBExpert, ExtractMetaData) und suche dort nach Deinem Generatorwert.

Was hat Deine DB für eine Endung, FDB oder GDB (Stichwort Schattenkopien)?

[Emwykey]

Zitat von hoika:

Hallo,
vielleicht wird ja in einem Trigger, der nicht so häufig verwendet wird,
der falsche Generatorwert drin.
Exportiere mal deine DB (IBExpert, ExtractMetaData) und suche dort nach Deinem Generatorwert.

Was hat Deine DB für eine Endung, FDB oder GDB (Stichwort Schattenkopien)?

Den Export kann ich versuchen, Dateiformat FDB

[Emwykey]

ok, danke! werde ich versuchen!

[jobo]

Zitat von Emwykey:

Sorry ich schreib das hier nebenher...
..

Der Generator wird Ausschließlich im Trigger angesprochen

..
ab und an wird der Generator auch direkt angesprochen ( daher die Abfrage auf ID is null)

Ich schreib das auch nebenher:

Sind die zitierten Aussagen oben nicht widersprüchlich?

Und,
es ist vollkommen wurscht, ob der Generator nebenher angesprochen wird.
Entscheidend ist, woher die Werte kommen, die in der Tabelle landen. Oder anders:
Du kannst dem Generator soviel Werte aus dem Kreuz leiern, wie Du magst. Und mit denen kannst Du machen, was Du willst.
Wichtig ist nur, dass in einer Tabelle die ID aus genau einem Generator kommt und in Deinem Fall sicherheitshalber bedingungslos, also ohne irgendwelche Prüfungen.

Es ist nicht ungewöhnlich, einen Generator als unique Quelle für mehrere oder auch viele Tabellen zu verwenden.
Es gibt sogar Dinge, die dafür sprechen.

Das gilt unabhängig von Deinem spezifischen Problem hier, die Reparatur bzw. Prüfung der DB Konsistenz würde ich als erstes machen und vor allem versuchen die Ursache zu finden.

[p80286]

wie überprüfst Du, daß der wert des Generators korrekt ist?
Wenn Du schreibst:

Zitat von Emwykey:

Denoch passiert es, dass von jetzt auf nachher der Wert des Generators zur Tabelle1_Archiv nicht mehr stimmt und somit natürlich auch das Insert/Update/Delete auf Tabelle1 fehlschlägt.

Habe ich leichte Bedenken, daß Du die Funktionsweise der Trigger/Generator-Kombination richtig verstanden hast. Für ein DELETE... oder UPDATE... wir der Generator nicht benötigt, da hierfür bereits Datensätze vorhanden sein müssen.

Ggf. wäre es günstig uns mal die Statements zu zeigen bei denen der Fehler auftritt.

Gruß
K-H

[hoika]

Hallo,
FDB als Endung ist schon mal gut, dann fällt mein Hinweis mit den Schattenkopien schon mal weg.

Welche genaue Version von Firebird hast Du?

Solche Fehler sind dann leider schwer zu finden.
Du musst versuchen, das zu reproduzieren.
Schreib Dir ein Extra-Programm, was Deine DB mit typischen Anfragen bombardiert
und versuche somit, den Fehler nachzustellen.
Wenn Dein Programm im Netzwerk läuft, dann starte es doppelt oder besser auf 2 Rechnern oder 2 VMs.

Ich hatte mal vor 'zig Jahren so einen Fall mit einer Paradox-DB beim Kunden (jaja, gab es damals).
"Index out of date", puh.
Ich hatte sogar einen gleichen (Windows-)Server aufgebaut, das Bombardier-Test-Programm auf 2 Rechnern gestartet,
und konnte diesen Fehler nicht nachstellen.

Mit der Umstellung auf IB/FB war das dann aber gelöst

[Emwykey]

Zitat von hoika:

Welche genaue Version von Firebird hast Du?

Wir arbeiten aktuell mit Firebird 2.5(3)

das mit dem reproduzieren kann ich auf jeden fall mal versuchen

[Emwykey]

Zitat von p80286:

wie überprüfst Du, daß der wert des Generators korrekt ist?
Wenn Du schreibst:

Zitat von Emwykey:

Denoch passiert es, dass von jetzt auf nachher der Wert des Generators zur Tabelle1_Archiv nicht mehr stimmt und somit natürlich auch das Insert/Update/Delete auf Tabelle1 fehlschlägt.

Habe ich leichte Bedenken, daß Du die Funktionsweise der Trigger/Generator-Kombination richtig verstanden hast. Für ein DELETE... oder UPDATE... wir der Generator nicht benötigt, da hierfür bereits Datensätze vorhanden sein müssen.

Ggf. wäre es günstig uns mal die Statements zu zeigen bei denen der Fehler auftritt.

Gruß
K-H

ich glaub eher du verstehst nicht ganz was ich gemeint habe. es gibt eine tabelle. diese wird normal bearbeitet. insert / update / delete. bei jeder aktion werden die werte der tabelle ( bei insert natürlich die neuen, bei update und delete die alten) in eine andere tabelle gescchrieben. diese andere tabelle wiederum holt sich ihre id über einen trigger+generator before insert natürlich.
und ich kann versichern, dass die statements absolut ok sind müsste aber jeden tabellen und feldnamen uws. ändern um sie hier einzustellen. darum geht es aber auch garnicht. das problem ist der generator der hängen bleibt - bei der selben anweisung bei der der vorher unbestimmte male problemlos funktioniert hat


Zur Frage wie ich den wert prüfen: da wie bereits erwähnt die id für tabelle1_archiv ausschließlich über den generator vergeben wird muss ich nur den generatorwert mit max id abgleichen. ist max id größer ( was in dem fall zutrifft ) ist natürlich der generator falsch - die id kann ja von nirgendwo sonst herkommen....