Firebird 2.5 Generator falsch - Trigger FireDAC

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