...klingt im Prinzip gut, geht aber schief wenn durch irgendwas (z.B. FireDAC) die ID
schon mit 0 (also numerisch 0, nicht dem Zustand NULL) vorbelegt wurde.
besser:
MMn: Entweder der Trigger in der
DB feuert gar nicht (weil durch irgendwas in FireDAC
das INSERT gar nicht erst bis zum Server durchkommt), oder er feuert zwar, macht
dann aber nichts, weil die ID nicht NULL sondern 0 ist.
1. reingrätschen kann ja nichts schaden, ja, was macht Firedac da ? Werden ohne zutun etwa Table-Felder automatisch bestzt ? Aber :
2. das mit der ID ist schon geklärt, der Trigger scheint schon zu feuern. In externem IBExpert (
bereits ca. 5mal gesagt) macht er das ja sowieso, aber auch in anderem eigenem Programm (allerdings mit FibPlus als Zugriffskomponenten)
3. Die Frage dreht sich nur noch darum, warum jetzt plötzlich der unique Key Ärger macht. Muss man das eventuell ähnlich einstellen, wie mit dem AutoInc-Feld ? Oder hängt das gar zusammen ? Ich sehe aber da nichts in FireDac, was irgendwie in diese Richtung gehen könnte.
4. Wie gesagt : bei leerer Tabelle schlägt der Insert fehl mit NR, die es noch gar nicht gibt. Und NR hat mit der ID nichts zu tun. Ist halt lediglich unique, was mein Programm besser sowieso der Datenbank im Fehlerfalle überlassen sollte.
@Perlsau : Davon ging ich auch aus. Der
DB muss aber offensichtlich das als AutoInc zu behandelnde Feld mitgeteilt werden. Die Frage lautet jetzt also, was FireDac da weshalb genau macht. Warum interessiert sich FireDac überhaupt um einen unique Key ?
Trigger/ID ist vorerst erledigt ! Also nochmals : der Trigger geht definitiv richtig ! Und der nicht vorhandene unique landet nicht in der
DB wegen
Code:
Problematic Key is ("NR" = 101
Die Nr. 101 ist doch gar nicht da !