FireDAC : Trigger geht nicht

[Frank Ingermann]

Hallo zusammen,

ich hoffe, ich darf hier mal kurz "reingrätschen" :

In dem Trigger steht:

IF (NEW.ID IS NULL) THEN
NEW.ID = GEN_ID(GEN_TEST_ID, 1);

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

IF ((NEW.ID IS NULL) or (NEW.ID=0)) THEN
NEW.ID = GEN_ID(GEN_TEST_ID, 1);

oder auch (macht das selbe, nur etwas kürzer):

IF (coalesce(NEW.ID,0) = 0) THEN // coalesce: falls NULL, nimm' das zweite Argument
NEW.ID = GEN_ID(GEN_TEST_ID, 1);

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.

lg, Frank

P.S. gibt es hier so etwas wie einen Thread zur Vorstellung neuer User?
("Neu" bin ich zwar nicht mehr, aber zumindest hier gerade neu... )

[Perlsau]

Soweit ich informiert bin, haben Trigger in der DB Vorrang vor Client-Triggern. Im konkreten Fall hätte dann der Trigger, der die Id-Erzeugung im Generator anstößt, Vorrang vor dem im Firedac-Query eingestellten Defaultwert. In FireDac gebe ich an, welcher Generator für die Erzeugung des Primary-Key (den ich ebenfalls angebe) zuständig ist. FireDac führt das aber nur aus, wenn in der DB nicht bereits ein Trigger das Setzen dieses Wertes anstößt.

Zitat von Frank Ingermann:

P.S. gibt es hier so etwas wie einen Thread zur Vorstellung neuer User? ("Neu" bin ich zwar nicht mehr, aber zumindest hier gerade neu... )

Nicht daß ich wüßte ... aber ein Sei Willkommen! kann ja nicht schaden

[Hansa]

Zitat von Frank Ingermann:

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

[jobo]

geth die Meldung noch weiter? Ich seh da "(" auf nicht zu. Ist die Nummer 101 vollständig oder ist da was abgeschnitten?
Mit welcher Aktion erzeugst Du diesen Fehler? Offenbar ja mittels Delphiprogramm.
Welche Werte stehen vor dem Post im Record? Ist "Nr" belegt oder leer?
Leer sollte es nicht sein, da es not null definiert ist.

[nahpets]

Sicher, dass die 101 noch nicht da ist?

Ausgehend von den Quelltextfragmenten, kann es die 101 nur einmal geben.

Zumindest gehe ich mal davon aus, dass du da eine For-Schleife mit sowas wiefor i := 0 to n hast. Wenn dem so ist, warum wird dann nicht schon bei Nr. 100 gemoppert?

Wenn i bei 1 beginnt, hieße das aber, dass bereits der erste Satz als Schlüsselverletzung angesehen wird. Dies erscheint mir dann aber doch ziemlich schräg, könnte aber bedeuten, dass irgend etwas konfigurationstechnisch dafür sorgt, dass jeder Datensatz mindestens zweimal (aus Sicht der Datenbank) dort ankommt.

Was passiert, wenn Du (vorerst) nach jedem Satz mal ein Commit machst? Quasiif i mod 1 = 0 then begin Zumindest müsstest Du bei einem satzweisen Commit ja dann nachschauen können, ob schon 'ne 101 da ist. Wenn nicht, dann muss das Problem bei FireDac liegen.

Eventuell könntest Du den Quelltext mal ein bisserl umbauen:

Delphi-Quellcode:

DM.DS.Insert;
DM.DS.FieldByName('NR').AsInteger := i + 100;
DM.DS.FieldByName('BEZ').AsInteger := i;
try
  DM.DS.Post;
except
  on e : Exception do begin
    DM.DS.Cancel;
    mem1.Lines.Add(Format('i = %d - %s'[i,e.Message]));
  end;
end;

Wie oft bekommst Du hier i = 1 zu sehen? Denn das müsste ja eigentlich zu dem Fehler führen.
Zugegeben sind mein Vorschläge gerade nur reines stochern im Nebel, darfst sie von daher gerne ignorieren

[Hansa]

Zitat von nahpets:

Sicher, dass die 101 noch nicht da ist?

Ausgehend von den Quelltextfragmenten, kann es die 101 nur einmal geben.

Es gibt sie nicht mal einmal. Das 1. Insert scheitert schon. Siehe Fehlermeldung. Ich versuche also, einen nicht vorhandenen Datensatz mit eingebautem unique Key in die DB einmalig einzufügen und das 1-mal und dann so was. Das i sollte schon hochgezählt werden, aber es besteht nur noch Folgendes : i := 0; Danach ist alles auskommentiert, was eigentlich geplant war. Jetzt kommt noch der Witz : Habe das Unique-Key-Feld Nicht-unique gemacht und der Fehler ist nicht weg ! Ok, Datenbank fast leer gemacht und immer noch dasselbe. Näcgster Ansatz wäre dann die DB an sich. Gibt ConnectionName da vielleicht falsche Namen zurück ? Die lasse ich mir nämlich vorsichtshalber anzeigen. Und sie beziehen sich auch auf die zu bearbeitende DB.

Wäre ja naheliegend, dass ich die falsche benutze. Sehe das aber nicht so.

[nahpets]

Moment, nochmal zum Mitschreiben. Du machst also nur noch das:

Delphi-Quellcode:

i := 0;
DM.DS.Insert;
DM.DS.FieldByName('NR').AsInteger := i + 100;
DM.DS.FieldByName('BEZ').AsInteger := i;
DM.DS.Post;

und das scheitert beim ersten Datensatz in eine leere Tabelle mit einer Schlüsselverletzung im Feld Nr in einer Tabelle, die für das Feld Nr keinen eindeutigen Schlüssel hat?

1. Drop Table und neumachen.
2. Erneut probieren, Fehler weg?
3. Wenn nein, neue Datenbank machen, nur diese Tabelle und den Trigger und erneut probieren.
4. Fehler weiter da? Rechner ausschalten und morgen erneut probieren Nein, ehrlich gesagt keine Ahnung.

Gibt es irgendeinen Cache, der Daten vorhält..., so dass das Programm irgend etwas "aus der Vergangenheit" sehen könnte, was in der Realität nicht mehr existiert?
Aber dann dürfte ja die Datenbank nicht meckern. Gibts da 'nen Clone von, auf den Du noch (irrtümlich) zugreifst?

Entwicklungsumgebung mal zugemacht?
Datenbank neu gestartet?
Neues, leeres Projekt mit nur dem Datenbankzugriff und dem Insert in diese Tabelle (nicht per Copy&Paste aus dem "alten" Projekt übernehmen, wer weiß, was jetzt da nicht stimmt)?
Kenne FireDac nicht (mein Delphi ist zu alt), gibt es denn da die Möglichkeit etwas so stark zu "verkonfigurieren", dass daraus ein derartiges Problem resultieren könnte?

Glaube nicht, dass ich hierzu noch irgendwas halbwegs sinnvolles schreiben könnte

[Frank Ingermann]

Hallo zusammen,

@Hansa: ich bin da "gebranntes Kind": wenn <irgendwas> mit IBExpert geht,
dann heißt das noch lange nicht, dass es mit Firebird per se geht...
(sorry, Holger...

"Der Trigger scheint zu feuern"...
Vergiss' das. Lege einen neuen Generator an, der NUR im Trigger erhöht wird.

Wenn der nach deinem Test erhöht wurde, dann wurde der Trigger gefeuert.
Sonst nicht. ("Generators run outside of transaction control!")

(Ob die Transaktion danach dann vlt. einem Rollback zum Opfer gefallen ist,
weisst Du dann aber immer noch nicht )

Die Sache mit dem Unique Key ist noch mal eine ganz andere Baustelle.

Ohne das Umfeld genauer zu kennen, kann ich nur mutmaßen: wenn die DB
meckert, daß es zum Zeitpunkt des Inserts schon einen Datensatz mit NR=<x>
gab, dann wird das wohl so gewesen sein...

Vlt. noch eine andere Instanz des Programms? Nicht-COMMITtete Transaktion?

Die Transaktionen in Fb funktionieren, dafür lege ich meine Hand in's Feuer(!).
Die Generatoren/Sequenzen auch. Wenn im Zusammenspiel zwischen Programm und
Fb-Server etwas nicht funktioniert, liegt das Problem erfahrungsgemäß
irgendwo in der Mitte

lg, Frank