Firebird Db Trigger Problem

[Privateer3000]

Hallöchen
ich komme grad irgendwie nicht weiter.
Ich habe einen Generator sowie einen Trigger
mittels IBEasy angelegt.
Wenn ich nun in der betreffenden Tabelle
einen neuen DS anlege passiert: nichts.

Code:

as
begin
  if ((new.ID is null) or (new.ID = 0)) then
  begin
    new.ID = gen_id( GENTEST, 1 );
  end
end

BEFORE INSERT und AKTIV sind eingesetzt.
Meiner Meinung nach ist die Tabelle in Ordnung
und der Generator auch.
Trotzdem wird keine ID angelegt wenn ein neuer DS angelegt wird (im IBEasy).
Mache ich was falsch?
Grüße

[mkinzler]

Der Wert wird erst beim Post gesetzt. Bei der Neuanlage ( + o.aä; kenne IBEasy nicht) bleibt das Feld ersteinmal lle (NULL).
Der Trigger wirkt auch nur wenn man diesen Wert nicht vor dem Abschliessen ändert ( oder mit 0 belegt)

[Privateer3000]

Danke Markus
das hatte ich auch gedacht
aber beim Post meckert er rum dass ID nicht leer sein darf.
Also greift irgendwie der Trigger nicht.
Wo kann ich noch nachsehen?

[mkinzler]

Ich glaube eher, dass dies ein Problem des Tools ist. Gib mal 0 an.

[Privateer3000]

Daran habe ich auch schon gedacht und
ein bissl herumgespielt, allerdings ohne Ergebnis.
Vllt. sollte ich eine andere GUI suchen.
Es gibt ja mehrere für FB.
Danke erstmal.

[alex517]

Hi,

du könnest mit dir auch "von Hand" eine neue ID holen
und diese dem Insert gleich mitgeben.

SQL-Code:

select
   gen_id( GEN_DeineTabelle_ID, 1 ) as NeueID 
from 
  RDB$Database

Das hat den Vorteil, dass für evt. Detail-Datensätze
gleich eine Master_ID bekannt ist.

alex

[mkinzler]

Das kann man aber auch durch RETURNING erreichen

[Privateer3000]

Danke für Eure Antworten
Ich hatte mich auch schon damit beschäftigt
http://www.firebirdsql.org/manual/de...rguide-de.html
es ist halt ein Umdenken nötig wenn man vorher nur Jet/Access benutzt hat.
Aber ist

Code:

select
    gen_id( GEN_DeineTabelle_ID, 1 ) as NeueID 
from 
  RDB$Database

auch Multiuser tauglich?
Ich werde mit einer Testanwendung erstmal
sehen ob IBEasy nicht triggert oder ob es in der DB ein Problem gibt.
Grüße & Danke

[mkinzler]

Zitat:

... auch Multiuser tauglich?

Ja deenn diese wird durch die semaphoren-gestützte Funktion gen_id(() gewährleistet

[Privateer3000]

Zitat:

Zitat von alex517 (Beitrag 1188495)

Hi,

du könnest mit dir auch "von Hand" eine neue ID holen
und diese dem Insert gleich mitgeben.

SQL-Code:

select
   gen_id( GEN_DeineTabelle_ID, 1 ) as NeueID 
from 
  RDB$Database

Das hat den Vorteil, dass für evt. Detail-Datensätze
gleich eine Master_ID bekannt ist.

alex

Schickt man das mit der gleichen TZSQL mit der
auch das Insert geschickt wird oder eine eigene?
Nutzt man evtl. dafür die TZUpdateSQL ( die für mich immer
noch rätselhaft ist).
Grüße

[mkinzler]

Kommt darauf an, ob Zeos RETURNING versteht, wenn ja:

SQL-Code:

insert into <Tabelle> ( ID, <weitere Felder>)
               values ( (select
                            gen_id( GEN_DeineTabelle_ID, 1 )  
                         from
                            RDB$Database), <weitere Werte>)
               RETURNING ID;

Sonst als getrennte Abfrage.

[Perlsau]

@Privateer3000:

Ich verwende zum Erstellen und Ändern von Firebird-Datenbank immer die Personalversion von IBExpert. Bevor du das Tool herunterlädst, mußt du dich registrieren.

IBExpert bietet beim Erstellen einer Tabelle die Möglichkeit, ein AutoInc-Feld zu definieren, wie in der angehängten Grafik dargestellt. Dabei kann man sich gleich automatisch den entsprechenden Trigger, den Generator und eine Prozedur generieren lassen. Die sehen dann so aus:

Prozedur SP_GEN_PROJEKT_ID

Code:

begin
  ID = gen_id(GEN_PROJEKT_ID, 1);
  suspend;
end

/* DLL */
SET TERM ^ ;

CREATE OR ALTER PROCEDURE SP_GEN_PROJEKT_ID 
returns (
    ID integer)
as
begin
  ID = gen_id(GEN_PROJEKT_ID, 1);
  suspend;
end^

SET TERM ; ^

/* Existing privileges on this procedure */

GRANT EXECUTE ON PROCEDURE SP_GEN_PROJEKT_ID TO SYSDBA;

Trigger PROJEKT_BI

Code:

as
begin
  if (new.IDX_PROJEKT is null) then
    new.IDX_PROJEKT = gen_id(GEN_PROJEKT_ID,1);
end

/* DLL */
/******************************************************************************/
/*        Following SET SQL DIALECT is just for the Database Comparer         */
/******************************************************************************/
SET SQL DIALECT 3;

CREATE GENERATOR GEN_PROJEKT_ID;

SET TERM ^ ;

CREATE OR ALTER TRIGGER PROJEKT_BI FOR PROJEKT
ACTIVE BEFORE INSERT POSITION 0
as
begin
  if (new.IDX_PROJEKT is null) then
    new.IDX_PROJEKT = gen_id(GEN_PROJEKT_ID,1);
end
^

SET TERM ; ^

Generator GEN_PROJEKT_ID

Code:

CREATE SEQUENCE GEN_PROJEKT_ID;
ALTER SEQUENCE GEN_PROJEKT_ID RESTART WITH 1;

/* Old syntax is:
CREATE GENERATOR GEN_PROJEKT_ID;
SET GENERATOR GEN_PROJEKT_ID TO 1;
*/

[Privateer3000]

Vielen Dank.
Ich habe mit IBExpert die Trigger ausprobiert
die ich im IBEasy erstellt habe.
Siehe da: sie funktionieren.
Es liegt am IBEasy.
Vielen Dank für den IBExpert Tipp.

[Privateer3000]

By the Way
kann man mit Generatoren auch ein Timestamp realisieren
so das beim DS erstellen ein Timestamp eingetragen wird?
Grüße

PS: Ich weiß offTopic, aber wollte deswegen keinen neuen Thread aufmachen

[Perlsau]

Zitat:

Zitat von Privateer3000 (Beitrag 1188693)

kann man mit Generatoren auch ein Timestamp realisieren

Ja. Das sollte dann aber eher in einen Trigger OnBeforeInsert oder OnBeforeUpdate.

[Hansa]

Zitat:

Zitat von Privateer3000 (Beitrag 1188531)

Aber ist

Code:

select
    gen_id( GEN_DeineTabelle_ID, 1 ) as NeueID 
from 
  RDB$Database

auch Multiuser tauglich?
Ich werde mit einer Testanwendung erstmal
sehen ob IBEasy nicht triggert oder ob es in der DB ein Problem gibt.
Grüße & Danke

Das ist schon Multiuser-fähig. Aber Generatoren sind nicht Transaktions-fähig ! Hier wurde mal der Tip gegeben, einen Generatoren-Wert zum Hochzählen von Rechnungsnummern zu verwenden, obwohl die lückenlos sein müssen. Da muss aber dann beachtet werden, dass das Finanzamt da ohne weiteres nicht mitspielt.

Denn es gilt : Trigger liegt in der DB. D.h., der schlägt immer zu, egal welches Programm für die DB benutzt wird ! Also eigenes Programm, IBExpert, anderes eigenes Programm oder sonstwas. Eventuell ausser IBEasy. :P

[mkinzler]

Zitat:

By the Way
kann man mit Generatoren auch ein Timestamp realisieren
so das beim DS erstellen ein Timestamp eingetragen wird?

Das würde ich eher durch einen Defaultwert CURRENT_TIMESTAMP bewerkstelligen

[Privateer3000]

Zitat:

Zitat von mkinzler (Beitrag 1188707)

Zitat:

By the Way
kann man mit Generatoren auch ein Timestamp realisieren
so das beim DS erstellen ein Timestamp eingetragen wird?

Das würde ich eher durch einen Defaultwert CURRENT_TIMESTAMP bewerkstelligen

Und wie? Darunter kann ich mir nichts vorstellen.
Direkt in den Generatorwert in dieser Syntax?

[Privateer3000]

Zitat:

Das ist schon Multiuser-fähig. Aber Generatoren sind nicht Transaktions-fähig ! Hier wurde mal der Tip gegeben, einen Generatoren-Wert zum Hochzählen von Rechnungsnummern zu verwenden, obwohl die lückenlos sein müssen. Da muss aber dann beachtet werden, dass das Finanzamt da ohne weiteres nicht mitspielt.

Denn es gilt : Trigger liegt in der DB. D.h., der schlägt immer zu, egal welches Programm für die DB benutzt wird ! Also eigenes Programm, IBExpert, anderes eigenes Programm oder sonstwas. Eventuell ausser IBEasy. :P

Aber im Multiuser MUSS ja sichergestellt sein, dass der nächste Wert auch dem gehört der ihn aufgerufen hat.
Wenn ich nur den Wert hole ohne ihn zu reservieren gehts schief. Oder liege ich da falsch...

[mkinzler]

Zitat:

Und wie? Darunter kann ich mir nichts vorstellen.
Direkt in den Generatorwert in dieser Syntax?

Nein in der Deklaration des Feldes der Tabelle. Für jedes Feld kann man einen Standardwert setzten der dann verwendet wird, wenn dieses beim Post NULL ist. Neben festen Werten gibt es auch Konstanten wie das erwähnte CURRENT_TIMESTAMP, welche immer den aktuellen Zeitwert erhält.

Zitat:

Aber im Multiuser MUSS ja sichergestellt sein, dass der nächste Wert auch dem gehört der ihn aufgerufen hat.
Wenn ich nur den Wert hole ohne ihn zu reservieren gehts schief. Oder liege ich da falsch...

Die Semaphore stellt sicher, dass kein anderer den selben Wert enrhält.Wenn du ihn aber holst ohne zu verwenden (Rollback), dann bleibt der Wert "reserviert". Es entshehen Lücken.

[Hansa]

Zitat:

Zitat von Privateer3000 (Beitrag 1188730)

Aber im Multiuser MUSS ja sichergestellt sein, dass der nächste Wert auch dem gehört der ihn aufgerufen hat....

Gerade deshalb werden Generatoren ja gnadenlos hochgezählt und das kann man per Rollback auch nicht rückgängig machen. Grundsätzlich sollte man Generatoren so behandeln : anlegen und vergessen (sofern die Trigger stimmen). 8-)

Das mit den Generatoren und Timestamp : auch gleich vergessen. Generator=Ganzzahl (integer oder Bigint). Perlsau hat wohl Generatoren und Trigger verwechselt. :stupid: Wenn ich nämlich z.B. ein Feld ANGELEGT in meiner Tabelle habe, dann hindert mich keiner dran, folgende Zeilen (hier in einem Insert-Trigger) hinzuzufügen:

Code:

  IF (NEW.ANGELEGT IS NULL) THEN
    NEW.ANGELEGT = CURRENT_TIMESTAMP;

[Privateer3000]

Vielen Dank @alle
das muss ich erstmal gut kauen und verdauen.
Langsam finde ich Gefallen an den Triggern :)

[Perlsau]

Zitat:

Zitat von Hansa (Beitrag 1188735)

Code:

  IF (NEW.ANGELEGT IS NULL) THEN
    NEW.ANGELEGT = CURRENT_TIMESTAMP;

Was aber muß ich machen, wenn ich jede Änderung des Datensatzes protokollieren will, also jedes Update?

Ruft nicht ein OnAfterUpdate-Trigger sich selbst wieder auf, wenn darin ein Update vorgenommen wird? Das würde dann doch eine Endlos-Schleife ergeben ...

[Hansa]

Update ? Ja, After-Update-Trigger. Ungefähr so :

Code:

  UPDATE TABELLE SET
    LETZTEAENDERUNG = CURRENT_TIMESTAMP
  WHERE (ID = OLD.ID) AND ((LETZTEAENDERUNG IS NULL) OR
        (LETZTEAENDERUNG <> CURRENT_TIMESTAMP));

Der Trigger macht doch das Update schon. Das Delphi-Dataset stösst ja das Update an, aber nicht für das Feld LETZTEAENDERUNG. Das darf im Programm nicht besetzt werden, damit der Trigger richtig zuschlägt.

[Perlsau]

Zitat:

Zitat von Hansa (Beitrag 1188761)

Code:

  UPDATE TABELLE SET
    LETZTEAENDERUNG = CURRENT_TIMESTAMP
  WHERE (ID = OLD.ID) AND ((LETZTEAENDERUNG IS NULL) OR
        (LETZTEAENDERUNG <> CURRENT_TIMESTAMP));

Hab Dank, das funktioniert einwandfrei.

[TBx]

Zitat:

Zitat von Hansa (Beitrag 1188761)

Code:

  UPDATE TABELLE SET
    LETZTEAENDERUNG = CURRENT_TIMESTAMP
  WHERE (ID = OLD.ID) AND ((LETZTEAENDERUNG IS NULL) OR
        (LETZTEAENDERUNG <> CURRENT_TIMESTAMP));

Hmm, ich würde das durch einen BeforeUpdateTrigger lösen:

Code:

CREATE TRIGGER TABELLE_BU FOR TABELLE 
  ACTIVE BEFORE UPDATE POSITION 1
AS 
BEGIN 
  new.LETZTEAENDERUNG = CURRENT_TIMESTAMP;
END

Wozu sollte hier noch ein erneutes Update gemacht werden?

[Hansa]

Na ja, man könnte das wohl auch so machen, wenn die WHERE - Klausel nicht wichtig ist. Minimalistischer gehts nimmer. :lol:

Das Beispiel gilt für folgenden Fall :

1. das Feld LETZTEAENDERUNG ist noch nicht besetzt : Datensatz wurde also noch nie geändert. Wird über IS NULL geprüft. Feld wird dann besetzt.

2. LETZTEAENDERUNG ist schon bestückt. Z.B. von Hand, maschinell aus alten Datenbeständen oder eben durch ein vorhergehendes Update. Nur mit IS NULL würde LETZTEAENDERUNG nur bei dem allerersten Update aktualisiert und danach nie mehr ! Also wird noch eine Bedingung gebraucht, dei für NOT IS NULL gilt !

Bitte vor Kommentaren genau lesen ! Das ist logisch nicht so einfach zusammenzubauen, wie es auf den ersten Blick aussieht !

Nebenbei bemerkt, man muss sich die Trigger wie Kettenhunde vorstellen. Der von TBx ist dabei vollständig von der Kette gelassen und beisst immer zu, ohne wenn und aber. Meiner ist etwas gezähmt.

[mkinzler]

Im Normalfall ist es auch gewollt das im Feld die letzte Änderung eines Datensatzes steht. Ich würde also wie TBX vom Normalfall ausgehen und nicht den Sonderfall bearbeiten, dass dies nur unter bestimmten Bedingungen gelten soll. Zudem mir die Sinnhaftigkeit deines Vergleiches nicht ganz einleuten will. ( Da ein CURRENT_TIMESTAMP nie NULL ist, ist der erste Teil der Bedingung überflüssig und wenn zufällig schon der gleiche Wert da stehen sollte [ was sehr unwahscheinlich ist] schadet es nicht diesen zu überschreiben).

Ich würde auch wie Thomas den BeforeInsert-Trigger bevorzugen, da der Timestamp ja zu diesem Vorgang gehört und sich auf die selbe Tabelle bezieht ( keine Logvorgang o.ä).

[Perlsau]

Zitat:

Zitat von TBx (Beitrag 1188795)

Hmm, ich würde das durch einen BeforeUpdateTrigger lösen:

Code:

CREATE TRIGGER TABELLE_BU FOR TABELLE 
  ACTIVE BEFORE UPDATE POSITION 1
AS 
BEGIN 
  new.LETZTEAENDERUNG = CURRENT_TIMESTAMP;
END

Wozu sollte hier noch ein erneutes Update gemacht werden?

Wenn ich deine Lösung anwende, erhalte ich in Delphi die Fehlermeldung, daß zu viele Trigger-Meldungen ausgelöst wurden. Das aktuelle Update (Post) wird dabei nicht ausgeführt. Allein die Lösung von Hansa funktioniert einwandfrei.

[TBx]

Zitat:

Zitat von Perlsau (Beitrag 1188844)

Wenn ich deine Lösung anwende, erhalte ich in Delphi die Fehlermeldung, daß zu viele Trigger-Meldungen ausgelöst wurden.

Diese Fehlermeldung kenne ich nicht.
Magst Du mal die genaue Meldung posten?
Hast Du noch weitere Trigger auf der Tabelle definiert?

[mkinzler]

Zitat:

Hast Du noch weitere Trigger auf der Tabelle definiert?

Dann musst du die Position entsprechend anpassen oder den Code der Trigger verschmelzen