SQL Automatisch zugeteilte Id ermitteln.

[Perlsau]

Zitat von Dejan Vu:

Wie ist denn die ID-Spalte bei einer Verbindung zu Firebird deklariert, damit sie nach einem INSERT weiß, welche ID vom RDBMS vergeben wurde?

Was meinst du damit? Die Id-Spalte ist in Firebird deklartiert und nicht im Client, der die Verbindung zur FB-Datenbank herstellt, z.B.:

Code:

ID_ZUSATZKLASSE  INTEGER NOT NULL
ALTER TABLE ZUSATZKLASSE ADD CONSTRAINT PK_ZUSATZKLASSE PRIMARY KEY (ID_ZUSATZKLASSE);

Willst du AutoInc-Funktionalität, erstellst du dir einen BeforeInsert- oder AfterInsert-Trigger, der einen Generator aufruft, von dem er sich den neuen Wert holt und in die Id-Spalte einträgt. IbExpert erledigt das automatisch, wenn man beim Erstellen der Tabelle die AutoInc-Checkbox aktiviert.

Vom Client aus kannst du dann – bei BeforeInsert – die Id-Spalte bereits vor dem Posten auslesen. Hast du AfterInsert eingestellt, mußt du dir mit dem Auslesen des aktuellen Generatorwertes behelfen:

Code:

select GEN_ID(GEN_ZUSATZKLASSE_ID,0) from RDB$DATABASE

... wobei der zweite Parameter den Increment-Wert darstellt.

[DeddyH]

Firebird kennt (IIRC ab der Version 2.0) eine RETURNING-Klausel, die genau für solche Zwecke gedacht ist, siehe z.B. hier.

[Perlsau]

Klar, wenn man via SQL-Befehlen direkte Inserts absetzt. Arbeitest du jedoch mit einer Datenmenge (Query), mittels derer du einen neuen Datensatz anzulegen gedenkst, nützt dir die Returning-Klausel nichts, denn Query.Append ist eine Procedure.

[Dejan Vu]

Ich muss mein Deutsch verbessern: Was ich meine, ist etwas wie die Property 'AutoGenerateValue' in einem TIntegerField. Normalerweise erzeugt der Provider einen Befehl, à la:

Code:

INSERT INTO Foo (ID,Value) VALUES (0,'Bar')

Der weiß doch nicht, das ID ein AutoInc-Feld ist. Erst wenn ich die o.g. Property entsprechend setze, wird der Befehl anders gerendert:

Code:

INSERT INTO Foo (Value) VALUES ('Bar') RETURNING ID

ADO kann die 'AutoGenerateValue' selbst richtig setzen, weil ja aus der Schemainformation (zumindest im SQL-Server) hervorgeht, das ID eine IDENTITY-Spalte ist. Nur, woran erkennt der Provider nun, das das Feld 'ID' bei Firebird eine Art AutoInc-Feld ist? Er wird ja wohl kaum die Trigger parsen...

[Perlsau]

Wenn deine Datenbank AutoInc in irgend einer Form unterstützt (bei Firebird z.B. über AfterInsert- bzw. BeforeInsert-Trigger und entsprechendem Generator) benötigst du keine clientseitige Initialisierung dieser Funktionalität, denn der Trigger löst automatisch beim Insert aus, und zwar völlig unabhängig vom Provider oder dem Sender des SQL-Befehhls.

Unterstützt dein DBMS das nicht, bieten einige DB-Komponenten die Möglichkeit, das via Client zu erledigen. Die entsprechenden Einstellungen zu wählen ist Aufgabe des Entwicklers. Der Provider muß nicht "wissen", ob es sich um ein "AutoInc-Feld" handelt.

Und ja: Kommuniziert man über Sachgebiete, die exakte Darstellungen erfordern (wie beispielsweise Mathematik oder eben auch eine Programmiersprache wie Pascal), ist es nicht wirklich zielführend, weiterhin die gewohnte Umgangssprache einzusetzen. Ohne ausreichende Kenntnis der Fachbegriffe und ihrer Bedeutung versagt man dann regelmäßig beim Versuch, Sachverhalte korrekt darzustellen.

[Uwe Raabe]

Zitat von Dejan Vu:

Nur, woran erkennt der Provider nun, das das Feld 'ID' bei Firebird eine Art AutoInc-Feld ist? Er wird ja wohl kaum die Trigger parsen...

Aus diesem Grund gibt es ja TAutoIncField bzw. den DataType ftAutoInc . Der Provider muss das nur passend zum Server umsetzen. Nicht alle können bzw. machen das. DbExpress hat da so seine Problemchen während FireDAC das ganz gut hinkriegt.

[Sir Rufo]

Zitat von Uwe Raabe:

Zitat von Dejan Vu:

Nur, woran erkennt der Provider nun, das das Feld 'ID' bei Firebird eine Art AutoInc-Feld ist? Er wird ja wohl kaum die Trigger parsen...

Aus diesem Grund gibt es ja TAutoIncField bzw. den DataType ftAutoInc . Der Provider muss das nur passend zum Server umsetzen. Nicht alle können bzw. machen das. DbExpress hat da so seine Problemchen während FireDAC das ganz gut hinkriegt.

Pssst, sag nicht sowas, das funktioniert immer ohne Wenn und aber, egal womit man darauf zugreift, in Ehrlichkeit, Amen

[Dejan Vu]

Ist schon klar. Nur ganz so automatisch, wie Perlsau das gesagt hat, scheint es dann doch nicht zu gehen. Die Felder muss man dann ggf. manuell anpassen.

[mkinzler]

Das RETURNING von FireBird wird ihm be der Verwendung von MySQL wenig bringen. In diesem Fall würde ich mich auch nicht darauf verlassen, dass der Datensatzzeiger nach dem Insert aauf dem richtigen Datensatz steht, sondern wie in der 1. Antwort beschrieben die saubere Variante wählen.

[DeddyH]

Das RETURNING hatte ich erwähnt, als von Firebird die Rede war. Weshalb man unter MySQL LAST_INSERT_ID verwenden sollte, ist in dem verlinkten Artikel aus der ersten Antwort erschöpfend beschrieben.