FireDAC : Trigger geht nicht

[Hansa]

Jetzt zum dritten mal, ein und derselbe Trigger der in IBExtert offensichtlich zuschlägt, schlägt offensichtlich über FireDAC nicht zu.

Code:

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

Das steht im Trigger, was sonst ? Wenn ich schreibe Table dann ist zumindest aus dem Zusammenhang zu schliessen, dass damit Database-Table gemeint ist und nicht irgendeine Table-Komponente. DM steht übrigens für DataModule und DS für Dataset, bzw. in diesem Fall für FDQuery. Dass es viele FireDac-Komponenten gibt weiss ich auch und ich benutze nicht nur die eine.

@nahpets : das habe ich auch schon probiert, also die ID von Hand vergeben. Aber auch dann kommt offensichtlich nichts in der DB an. Fehlermeldung bleibt aber aus.

@Uwe : beim Edit ist die ID ja schon da und der Trigger tritt nicht in Aktion, ist ja klar, aber ich ändere doch zumindest die anderen beiden Felder. Auch davon ist nichts zu sehen.

Das dürfte alles nicht viel sein, irgendeine dumme Einstellung, aber momentan ein Rätsel. Mir fällt langsam nichts mehr ein, wo ich nachgucken soll

[nahpets]

Was steht bitte in der Create-Anweisung des Triggers:

Delphi-Quellcode:

CREATE TRIGGER trigger-name for table-name
   [ACTIVE | INACTIVE]
   {BEFORE | AFTER} <actions>
   [POSITION number]
   AS

Before oder After?
Kannst Du im Trigger irgendeine (wie auch immer geartete) Ausgabe machen, um zu erkennen, ob der Trigger beim Aufruf aus dem Programm überhaupt aktiv wird?
Er scheint ja zuweilen zu arbeiten, oder konntest Du schon sicherstellen (dich vergewissern), dass er auf jeden Fall immer aufgerufen wird.

Oder:

Könntest Du ein (vorübergehendes) Logging in den Trigger einbauen, analog zu http://www.firebirdsql.org/refdocs/l...exception.html

Eigentlich erscheint mir der Trigger korrekt zu sein, er dürfte ja diesem Beispiel entsprechen:

Delphi-Quellcode:

create trigger biu_parts for parts
  before insert or update
as
begin
  /* conditional code when inserting: */
  if (inserting and new.id is null)
    then new.id = gen_id(gen_partrec_id, 1);
  
  /* common code: */
  new.partname_upper = upper(new.partname);
end

Wenn Du im Trigger eine Exception schmeißt (ohne jede Bedingung, immer und grundsätzlichEXCEPTION [<exception-name> [custom-message]] , bekommst Du sie aus dem Programm zu sehen? Wenn nein, dann wird der Trigger (höchstwahrscheinlich) nicht immer aufgerufen.
Allerdings hab' ich überhaupt keine Idee, warum es eine derartige Situation geben sollte.

[Daniel]

FireDAC erkennt das ID-Feld als Primärschlüssel und fordert daher, dass es einen Wert erhält. Dieser wird aber erst auf dem Server (!) durch Deinen Trigger zugewiesen. Man muss FireDAC also dazu bringen, ein Feld, welches als "required" markiert ist, leer zum Server zu senden. Das geht entweder, indem man es als "AutoInc"-Feld deklariert (siehe Uwe) oder aber, indem man in den Update-Options die Eigenschaft "CheckRequired" auf FALSE setzt.

Bei Deinem Code kommt es gar nicht soweit, dass der Trigger angestossen werden könnte, weil FireDAC den Post-Request als unvollständig betrachtet und ablehnt. Die Daten erreichen den Server nicht einmal.

[Hansa]

@nahpets : das mit der Exception (für mkinzler : Datenbank-Exception ) hatte ich schon gemacht und deshalb gesehen, dass der Trigger tatsächlich nicht zuschlägt (natürlich für Insert ein BI-Trigger).

Und die Ursache für den Effekt ist tatsächlich genau das, was Uwe und Daniel angemerkt haben. Ich habe FireDAC eben nicht mitgeteilt, dass die ID ein über Trigger automatisch aktualisiertes Feld ist. Ich habe das jetzt nachgeholt und der ursprüngliche Fehler ist weg. Das haben sie aber trotz der Wichtigkeit unnötigerweise gut in OI-Untermenü versteckt bei Update-Options.

Jetzt gibt es aber noch ein ähnliches Phänomen :

Zitat:

violation on primary or unique key...Problematic Key is ("NR" = 101

Die Tabelle besteht ja nur aus ID,NR,BEZ, wobei NR als unique deklariert ist. Was ist das nun wieder ? Die Tabelle ist momentan leer.

[hoika]

Hallo,
vielleicht hilft das ja.

http://docwiki.embarcadero.com/RADSt..._%28FireDAC%29

Also:
Set TField.AutoGenerateValue to arAutoInc for an auto-incrementing field. This method does not create a TFDAutoIncField, it works with any field type, and may require additional field properties setup, like setting ProviderFlags, Required and ReadOnly.


Zu spät ... (AutoInc)
So, jetzt zeig mal deine Tabellenstruktur.


Heiko

[Hansa]

Tabelle ? Im Prinzip steht die oben schon, egal.

Code:

CREATE TABLE WG8 (
    ID               INTEGER NOT NULL,
    NR               INTEGER NOT NULL,
    BEZ              VARCHAR(25) DEFAULT '' NOT NULL
);
ALTER TABLE WG8 ADD CONSTRAINT UNQ_WG8 UNIQUE (NR);
ALTER TABLE WG8 ADD CONSTRAINT PK_WG8 PRIMARY KEY (ID);

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

[Uwe Raabe]

Zitat von Hansa:

Das dürfte alles nicht viel sein, irgendeine dumme Einstellung, aber momentan ein Rätsel. Mir fällt langsam nichts mehr ein, wo ich nachgucken soll

Wie schon erwähnt, prüfe doch ob das ID-Feld wirklich als TFDAutoIncField erkannt wurde.

Dann das obligatorische "ist der Stecker drin?", sprich: bist du auch sicher mit derselben Datenbank verbunden?

Wenn es machbar ist, lannst du ja auch mal die nötigen Sourcen hier anhängen, damit wir auch was sehen können.