![]() |
AW: Firebird 2.5 Generator falsch - Trigger FireDAC
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 ;) |
AW: Firebird 2.5 Generator falsch - Trigger FireDAC
Zitat:
|
AW: Firebird 2.5 Generator falsch - Trigger FireDAC
Zitat:
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.... |
AW: Firebird 2.5 Generator falsch - Trigger FireDAC
Zitat:
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. |
AW: Firebird 2.5 Generator falsch - Trigger FireDAC
Zitat:
das mit dem reproduzieren kann ich auf jeden fall mal versuchen |
AW: Firebird 2.5 Generator falsch - Trigger FireDAC
Zitat:
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. |
AW: Firebird 2.5 Generator falsch - Trigger FireDAC
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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:20 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz