Firebird : Tabelle erstellen mit AutoInc-Feld

[mkinzler]

IMHO sind alle Lösungen, welche auf Generatoren aufsetzen gleich gut. Seien es jetzt durch Einsatz eines Triggers, einer SP, direkt im Statement oder dem Einsatz von clientseitiger Komponenten, welche darauf aufsetzen (TZSequence usw.)

[Elvis]

Zitat von alex517:

Zitat von Elvis:

Nicht zu schnell widersprechen! ( )

Oh, doch!

Gibst nicht auf was?

Zitat von alex517:

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!

Also die Rechungsposten haben einen FK auf die Rechung? Das heißt die Rechung muss existieren bevor du den Rechnungsposten einfügen kannst? Wenn du jetzt mit Ja/Ja antwortest, dann war das kein Grund diese potentielle Schlüsselverletzung im Trigger zu lassen.
Pseudo code:

Delphi-Quellcode:

using transaction := deineConnection.BeginTransaction() do
begin
  using command := connection.CreateCommand() do
  begin
    command.CommandText := 'INSERT INTO Rechungen(blabla) VALUES(:Blabla) RETURINNG ID';
    command.Parameters.Add('Blabla', 1);
    var rechungsId := command.ExecuteScalar() as Integer;
    command.CommandText := 'INSERT INTO RechungsPostenen(Rechung) VALUES(:Rechung) RETURNING ID';
    command.Parameters.Add('Rechung', rechungsId);
    var rechungsPostenId := command.ExecuteScalar() as Integer;
    ...
  end;
 
  transaction.Commit();
end;

Zitat:

Ä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

Zitat:

Zitat von Elvis:

Hatte ich das wirklich so unverständlich geschrieben?

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

Kann gar nicht sein....

Zitat:

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

Ganz genau!

Zitat von mkinzler:

IMHO sind alle Lösungen, welche auf Generatoren aufsetzen gleich gut. Seien es jetzt durch Einsatz eines Triggers, einer SP, direkt im Statement oder dem Einsatz von clientseitiger Komponenten, welche darauf aufsetzen (TZSequence usw.)

Wenn ich 2 Lösungen für ein Problem habe, und die eine mindestens ein weiteres Problem bewirken kann, ohne Vorteile zu bringen...
Dann können nicht beide Lösungen gleich gut sein.

[Hansa]

Zitat von Elvis:

Wenn ich 2 Lösungen für ein Problem habe, und die eine mindestens ein weiteres Problem bewirken kann, ohne Vorteile zu bringen...
Dann können nicht beide Lösungen gleich gut sein.

Du hast dabei vergessen : viele Wege führen nach Rom. Und dann noch, dass Alex sowieso Recht hat.

Er hat das klassische Bsp. der Rechnung erklärt. Genau so nuss es gemacht werden. Also wird Rückgabewert gebraucht. Der Trigger scheidet somit aus und die beiden Möglichkeiten bestehen dann darin eine SP zu verwenden oder eben FB 2.0. Beides ist für den Zweck gut und macht keine Probleme.

[Elvis]

Sorry Alex, "schöne Pfingsten" vergessen.


Und nun die quartalsmäßige Antwort an Hansa:

Zitat von Hansa:

Er hat das klassische Bsp. der Rechnung erklärt. Genau so nuss es gemacht werden. Also wird Rückgabewert gebraucht. Der Trigger scheidet somit aus...

Warum kannst du dir nicht einfach angewöhnen nicht auf meine Beiträge zu antworten? Du hast natürlich wieder absolut gar nix kapiert, in dem Fall dass das erste Insert direkt die Rechnungs-ID zurückgegeben hat.
Deine "Kompetenz" beginnt und endet bei Firebird, und selbst da hast du absolut keinen Plan.

Kleiner Tipp an alle anderen, wenn es euch so wie mir gerade geht[1], versucht das was ich normalerweise auch mache: Versucht ihn zu ignoriert...


[1] Hansa hat auf einen Beitrag von euch geantwortet

[alex517]

Zitat von Elvis:

Also die Rechungsposten haben einen FK auf die Rechung? Das heißt die Rechung muss existieren bevor du den Rechnungsposten einfügen kannst? Wenn du jetzt mit Ja/Ja antwortest, dann war das kein Grund diese potentielle Schlüsselverletzung im Trigger zu lassen.

Ich verstehe nicht so richtig was du damit sagen möchtest.
Aber ich werte ich das einfach als Zustimmung zu meiner Darstellung. Überredet?


alex

[Elvis]

Zitat von alex517:

Ich verstehe nicht so richtig was du damit sagen möchtest.

Was da steht.
IOW, dein Einwand für das manuelle Generatorgefriemel und die Lücke im Trigger, die es ermöglicht eine ID in die Tabelle einzufügen, die als DeinGenerator.NextValue ist.
Ich wollte zeigen dass es mit "Returning" auch in dem von dir geschilderten Fall einfacher ist. Wenn zusätzlich die Lücke aus dem Trigger entfernt werden kann ist's ja nur besser.
Schließlich kannst du ja nur dann einen FK von Rechnungsposten auf Rechungen haben wenn der Rechungsdatensatz existiert, bevor du den Rechungsposten einfügst.

Zitat:

Aber ich werte ich das einfach als Zustimmung zu meiner Darstellung. Überredet?

Tsss.... Dickkopf....

[alex517]

Zitat von Elvis:

Ich wollte zeigen dass es mit "Returning" auch in dem von dir geschilderten Fall einfacher ist.

Ja, sofern bereits FB2.x verwendet wird.

Zitat von Elvis:

Wenn zusätzlich die Lücke aus dem Trigger entfernt werden kann ist's ja nur besser.

Jetzt verstehe ich erst, was du mit "Lücke im Trigger" meinst.
Diese Lücke ist aber nur theoretisch, da praktisch das Programm die ID vor dem Insert aus dem Generator holt.


Allerdings bekommst du mit deinem "lückenslosen"-Trigger u.U. Probleme:
z.B beim Import bestehender verlinkter Daten, der Trigger muß dann ggf. deaktiviert werden.


von

Zitat:

Tsss.... Dickkopf....

So bin ich..

alex