Firebird : Tabelle erstellen mit AutoInc-Feld

[Hansa]

Das steht in Deinem ersten Beitrag, sofern man die überflüssige SP weg lässt. Mehr ist es nicht. Es gilt allerdings, die ID nicht selber einzutragen. Das muss dann schon der Trigger machen, damit auch die MGA greift.

[RWarnecke]

Ich hätte noch 2 Fragen noch dazu :
1.) Verstehe ich das richtig, wenn ich diesen Teil weglasse

SQL-Code:

SET TERM ^ ;

create procedure sp_gen_produkte_id
returns (id integer)
as
begin
  id = gen_id(gen_produkte_id, 1);
  suspend;
end
^

SET TERM ; ^

Dann kann ich dem Problem aus dem Weg gehen, welches Elvis angesprochen hat ?

2.) Und was ist zum Teufel eine Multi-Generationen-Architektur (MGA) ?

[Hansa]

Ja, wegen der MGA sollte gar kein Problem entstehen. Die SP ist ein Ersatz für einen vor FB 2.0 nicht vorhandenen Trigger, der auch Rückgabewerte liefert. Werden die überhaupt gebraucht ? Im Normalfall überlässt man die IDs der DB und basta.

[mkinzler]

Der Trigger liefert immer noch keinen Rückgabewert, sondern das Insert-Statement. Man kann aber die ID auch vom Client setzen, solange man den Generator verwendet

[Hansa]

Zitat:

Zitat von mkinzler

Der Trigger liefert immer noch keinen Rückgabewert..

So, wie er da steht sichelich nicht. Wird der jetzt dringend gebraucht oder doch nicht ? Bevor dies nicht geklärt ist, lohnt keine Diskussion.

[mkinzler]

Zitat:

So, wie er da steht sichelich nicht

Ein Trigger liefert nie ienen Rückgabewert an den Client, weil er ja nicht von ihm aufgerufen wird.

[alex517]

Hi,

Zitat:

Zitat von Elvis

Vor Firebird 2.0 war kein konsistentes Handling von generator-basierten Pks möglich.
Erst die neue Returning-Clause erlaubt es.

Das ist nicht richtig!

Ich habe generell folgende Vorgehensweise:

1. Alle Tabellen haben ein PK-Feld "ID".

2. Diese ID wird ggf. durch einen Trigger, wie RWarnecke ihn schon verwendet, gesetzt

SQL-Code:

create trigger produkte_bi for produkte
active before insert position 0
as
begin
  if (new.id is null) then
    new.id = gen_id(GEN_PRODUKTE_ID,1);
end

3. Wenn es das Programm noch vor dem Absetzen eines Statements eine neue ID erfordert, z.B. für ein Insert
bei Master-Detail Verknüpfungen, so wird diese neue ID vorher explizit durch das Programm geholt.
Das kann mittels der verwendeten Komponenten (bei mir FIBPlus) erfolgen oder
über eine eigene Query mit folgendem Statement (FIBPlus macht auch nichts anderes):

SQL-Code:

select GEN_ID(GEN_PRODUKTE_ID, 1) from RDB$DATABASE

Ich brauche also keine extra SP und ein "konsistentes Handling von generator-basierten Pks"
ist auch auch vor FB 2.0 gewährleistet.

Unter FB2.x kann Rückgabe der ID wie Elvis schrieb mit "INSERT .. RETURNING ID" verfolgen.
Damit entfällt der Punkt 3.
Den Trigger würde ich aber immer beibehalten.


alex

[Elvis]

Zitat:

Zitat von alex517

Zitat:

Zitat von Elvis

Vor Firebird 2.0 war kein konsistentes Handling von generator-basierten Pks möglich.
Erst die neue Returning-Clause erlaubt es.

Das ist nicht richtig!

Nicht zu schnell widersprechen! :warn: ( ;) )

Zitat:

Ich habe generell folgende Vorgehensweise:...

Die hattest nicht nur du, die hatte jeder andere auch, der die ID des neuen Datensatzes in der dunklen Pre-FB2.0-Ära brauchte.

Zitat:

Ich brauche also keine extra SP und ein "konsistentes Handling von generator-basierten Pks"
ist auch auch vor FB 2.0 gewährleistet.

Und ich hoffe, dass du in der Doku deiner Software hinterlegt hast, dass niemand einen Wert für die ID angibt, außer er hat ihn vorher zu Fuss aus dem Generator geholt.
Ansonsten schreibt einer eine 1000 rein und irgendwann, 3 Wochen später, will dein Programm über den friemeligen "Generator abfragen & Wert beim Insert mitgeben"-Weg einen Datensatz einfügen und es knallt! Nun, irgendwann musste der Generator ja die 1000 erreichen. :mrgreen:

Zitat:

Unter FB2.x kann Rückgabe der ID wie Elvis schrieb mit "INSERT .. RETURNING ID" verfolgen.
Damit entfällt der Punkt 3.
Den Trigger würde ich aber immer beibehalten.

Natürlich braucht man den Trigger, er sollte die ID aber bedingungslos aus dem Generator setzen, auch wenn beim Insert schon ein Wert dafür angegeben wurde.

Hatte ich das wirklich so unverständlich geschrieben? :gruebel:

[Hansa]

Zitat:

Zitat von Elvis

...der die ID des neuen Datensatzes in der dunklen Pre-FB2.0-Ära brauchte...

in dieser "dunklen Ära" hat man eben eine SP benutzt, um direkt nach dem Einfügen eines Datensatzes die ID zu erhalten. Ein Trigger ist nichts anderes, als eine spezielle SP.

[alex517]

Zitat:

Zitat von Elvis

Nicht zu schnell widersprechen! :warn: ( ;) )

:warn: Oh, doch! :wink:

Zitat:

Zitat von Elvis

Und ich hoffe, dass du in der Doku deiner Software hinterlegt hast, dass niemand einen Wert für die ID angibt, außer er hat ihn vorher zu Fuss aus dem Generator geholt.
Ansonsten schreibt einer eine 1000 rein und irgendwann, 3 Wochen später, will dein Programm über den friemeligen "Generator abfragen & Wert beim Insert mitgeben"-Weg einen Datensatz einfügen und es knallt! Nun, irgendwann musste der Generator ja die 1000 erreichen. :mrgreen:

Das Holen der ID über

SQL-Code:

select GEN_ID(GEN_..._ID, 1) from rdb$database

erfolgt durch das Programm direkt vor dem Absetzen des Insert-Statements und ist in keinem Fall dem Benutzer überlassen.
Da die neue ID durch den selben Generator erzeugt wird, der auch im Trigger Verwendung findet, kann es niemals vorkommen, dass die IDs doppelt vergeben werden.
Der Vorgang der ID-Vergabe ist also in beiden Fällen (Trigger/select GEN_ID(..)) identisch, er wird nur falls notwendig in das Programm vorverlegt.

Zitat:

Zitat von Elvis

Natürlich braucht man den Trigger, er sollte die ID aber bedingungslos aus dem Generator setzen, auch wenn beim Insert schon ein Wert dafür angegeben wurde.

Dazu folgendes Szenario:
Ich generiere eine NEUE Rechnung (Rech) mit Rechnungsposten (RPosten) im Formular.
Da Rech- und RPosten-Daten in einer Transaktion gespeichert werden müssen, benötige ich vorher die ID der Rechnung, um diese
in den RPosten-Daten als Link(FK) auf die Rech eintragen zu können. Ich hole mir, wie oben beschrieben, explizit eine neu ID, und gebe diese beim Insert sowohl der Rechnung als auch den RPosten mit.
Fertig!
Äh.., natürlich nur wenn der Trigger nicht einfach bedingungslos der Rechnung eine andere ID verpasst.
Aber den Trigger habe ja ich angelegt und nicht Elvis :wink:

Zitat:

Zitat von Elvis

Hatte ich das wirklich so unverständlich geschrieben? :gruebel:

Nein, nicht unverständlich, aber ich denke, dass ich Recht habe.

Es ist also keine dunkle Ära, man muss nur die Augen aufmachen, damit es hell wird! :mrgreen:

Schöne Pfingsten
alex

:cheers: