Firebird 2.5 Generator falsch - Trigger FireDAC

[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 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?

Nein, die trigger werden einfach für jede tabelle identisch erstellt, da es hierfür eine funktion gibt. bei meiner tabelle bei der der fehler akut auftrat wird immer über den trigger + generator mit der id versehen, dh dieser generator im speziellen wird ausschliesslich über den trigger angesprochen. andere generatoren welche auch direkt angesprochen werden (zum teil, nicht immer) zeigen aber immer wieder das selbe seltsame verhalten.

[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....

[jobo]

Zitat von Emwykey:

ist max id größer ( was in dem fall zutrifft ) ist natürlich der generator falsch - die id kann ja von nirgendwo sonst herkommen....

Gemäß Trigger aus Beitrag 1 ist das ein Denkfehler.

Der Trigger erlaubt ohne weiteres die manuelle Vergabe eine beliebigen ID, von sich aus größer oder kleiner als der aktuelle Generatorstand. Die Formulierung im Triggercode erlaubt das "Überschreiben" des Generatorwertes, genauer der Trigger unterbindet seine Tätigkeit freiwillig, wenn er bereits einen Wert vorfindet.

Der Triger bzw. das Gesamtkonstrukt ist also nicht wasserdicht!

In der Praxis wird das "kleiner" nur selten oder fast nie oder nie eintreffen, wenn alle Werte kleiner als der aktuelle Generatorwert bündig vergeben wurden und demzufolge eine Schlüsselverletzung eintritt, wenn "blind" eine ID kleiner als Generator eingefügt wird.
Jemand der also manuell einen Datensatz eintragen will, fragt entweder selber gleich den Generator ab oder max(id) oder stochert solange, bis der geratene Wert größer als der Generator ist.
Dann ergibt Deine Prüfung ein falsch, max(id) ist dann kleiner als der Genererator.

[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 jobo:

Zitat von Emwykey:

ist max id größer ( was in dem fall zutrifft ) ist natürlich der generator falsch - die id kann ja von nirgendwo sonst herkommen....

Gemäß Trigger aus Beitrag 1 ist das ein Denkfehler.

Der Trigger erlaubt ohne weiteres die manuelle Vergabe eine beliebigen ID, von sich aus größer oder kleiner als der aktuelle Generatorstand. Die Formulierung im Triggercode erlaubt das "Überschreiben" des Generatorwertes, genauer der Trigger unterbindet seine Tätigkeit freiwillig, wenn er bereits einen Wert vorfindet.

Der Triger bzw. das Gesamtkonstrukt ist also nicht wasserdicht!

In der Praxis wird das "kleiner" nur selten oder fast nie oder nie eintreffen, wenn alle Werte kleiner als der aktuelle Generatorwert bündig vergeben wurden und demzufolge eine Schlüsselverletzung eintritt, wenn "blind" eine ID kleiner als Generator eingefügt wird.
Jemand der also manuell einen Datensatz eintragen will, fragt entweder selber gleich den Generator ab oder max(id) oder stochert solange, bis der geratene Wert größer als der Generator ist.
Dann ergibt Deine Prüfung ein falsch, max(id) ist dann kleiner als der Genererator.

bitte noch einmal. in diesem fall wird ZU KEINER ZEIT UND UNTER KEINEN UMSTÄNDEN JEMALS eine ID händisch vergeben. jede einzelne ID kommt vom generator. es ist egal, dass der trigger das theoretisch zulässt, da dieser wert niemals anderweitig initialisiert wird.
Das liegt daran, dass die tabelle1_archiv ( das gilt nur für diese tabelle, hier tritt das problem auch, nicht ausschliesslich, auf) wirklich ausschliesslich über die 3 trigger auf der tabelle1 angesprochen wird in welchen der wert ID nicht vorkommt.

[jobo]

Ja ach, das kannst Du meinetwegen so sehen und auch darauf beharren.
Ich spar mir jetzt eine Aufzählung von hypothetischen Möglichkeiten, die eingetreten sein können, Murphy's Law usw., die Deine Aussage zunichte machen können.

Ich stelle nur ein paar Fragen und liefere Hinweise, denn ich sehe das so:
Datenbanken sind dafür da, die Einhaltung bestimmter Regeln zu erzwingen. Genau dafür sind sie gemacht, das ist im Zweifel ihr Erfolgsrezept. ACID konforme Datenbanken machen das nicht einfach irgendwie, sondern sie garantieren(!) es.

Die Logik "kann nicht sein, weil wäre zwar möglich, kommt aber nicht vor" (die streng genommen nicht logisch ist), ist eine vollkommen unnötige.
Die Logik oder ihre Aussage wird auch nicht besser, wenn man dazu auf die Bibel schwört.
Jedes "Loch" was ich stopfen kann, stopfe ich, spätestens wenn Probleme auftreten, die sich mit der lachsen Handhabung in Verbindung bringen lassen. Warum soll ich mir das Leben schwer machen mit "hätte, hätte Fahrradkette"?

Was du schilderst, wäre ohne gefundene Erklärung und mit erwiesener Reproduzierbarkeit ein handfester Bug.
Meine Erfahrung ist, dass es besonders auf diesem grundsätzlichen Niveau solche Bugs viel seltener gibt, als sie herbeigerufen werden.
Das zeigt sich idR. bei hinreichend gründlicher Prüfung. Dazu gehört der absolute Ausschluss aller "variablen" Faktoren, z.B. dieser Trigger.

Was Du letztlich mit den Informationen hier im Thread machst, ist natürlich Deine Sache.