CREATE TRIGGER trgTTEST_BI_V1 for TTEST
active before insert position 0
as
begin
  new.id = gen_id( gidTest, 1 );
end

Probleme mit Trigger Version 1:

Dieser erledigt die Arbeit - aber er "verschwendet" auch jedes mal einen Generatorwert, wenn im INSERT-Befehl bereits ein generierter Wert für die ID übergeben wurde. Es wäre also effektiver, nur dann einen neuen Wert zu generieren, wenn nicht bereits einer im INSERT-Befehl enthalten war:

CREATE TRIGGER trgTTEST_BI_V2 for TTEST
active before insert position 0
as
begin
  if (ne    w.idisnullthen
  begin
    new.id = gen_id( gidTest, 1 );
  end
end

Probleme mit Trigger Version 2:

Manche Zugriffskomponenten haben die "dumme Angewohnheit", alle Spaltenwerte in einem Insert-Befehl vorzubelegen. Die Felder, die man nicht explizit setzt, bekommen Vorgabewerte - üblicherweise 0 für Integer-Spalten. In diesem Falle würde der obige Trigger nicht funktionieren: Er würde sehen, dass die ID-Spalte nicht den Zustand NULL, sondern den Wert 0 hat, und würde deshalb keine neue ID generieren. Man könnte den Satz dennoch speichern - aber nur einen... der zweite würde fehlschlagen. Es ist ohnehin eine gute Idee, die 0 als normalen ID-Wert zu "verbannen", allein schon um Verwechslungen zwischen NULL und 0 zu vermeiden. Man könnte z.B. einen speziellen Datensatz mit einer ID von 0 zur Speicherung der eigenen Vorgabewerte jeder Spalte in der Tabelle verwenden.

CREATE TRIGGER trgTTEST_BI_V3 for TTEST
active before insert position 0
as
begin
  if ((new.id is null) or (new.id = 0)) then
  begin
    new.id = gen_id( gidTest, 1 );
  end
end

Nun, da wir einen robust funktionierenden ID-Trigger haben, werden die folgenden Absätze erläutern, warum man den meistens gar nicht braucht:

Das Grundproblem mit IDs, die in Before-Insert-Triggern zugewiesen werden, ist, dass sie die IDs serverseitig erzeugen, nachdem man den Insert-Befehl zum Server geschickt hat. Das heißt schlicht und ergreifend, dass es keinen sicheren Weg gibt, von der Client-Seite aus zu erfahren, welche ID für den gerade erzeugten Satz vergeben wurde.

Man könnte nach dem INSERT den aktuellen Stand des Generators abfragen, aber im Mehrbenutzerbetrieb kann man nicht wirklich sicher sein, dass es die ID des eigenen Datensatzes ist (wegen der Transaktionskontrolle).

Generiert man aber einen neuen Generatorwert vorher, und füllt die ID-Spalte im Insert-Befehl mit diesem Wert, dann kann man den Datensatz einfach mit einem "Select ... where ID=<GenWert>" aus der Datenbank holen, um z.B. zu sehen, welche Vorgabewert greifen oder welche Spalten durch Insert-Trigger verändert wurden. Dies funktioniert deshalb besonders gut, weil man üblicherweise einen eindeutigen Primärindex für die ID-Spalte hat, und das sind so ungefähr die schnellsten Indizes, die man kriegen kann - sie sind unschlagbar in punkto Selektivität, und meist auch kleiner als Indizes für Textfelder vom Typ CHAR(n) (gilt für n>8, abhängig von Zeichensatz und Sortierreihenfolge)

Fazit des Ganzen:

Man sollte immer einen Before Insert-Trigger erzeugen, um absolut sicher zu sein, dass jeder neue Datensatz eine eindeutige ID erhält, selbst wenn im Insert-Befehl keine übergeben wurde.

Hat man eine SQL-mäßig "geschlossene" Datenbank (d.h. die eigene Applikation ist die einzige Quelle neuer Datensätze), dann kann man den Trigger weglassen. Dann muss man aber IMMER einen Generatorwert vor dem Insert holen und ihn im Insert-Befehl mitübergeben. Das selbe gilt selbstverständlich für Inserts, die aus Stored Procedures oder Triggern heraus erfolgen.