SQL Automatisch zugeteilte Id ermitteln.

[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.

[Perlsau]

Zitat von 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.

Vielleicht solltest du nicht nur deine Ausdruckfähigkeiten verbessern, sondern auch deine Lesekompentenz: Ich habe ausdrücklich geschrieben, daß die Erzeugung einer fortlaufenden Id genau dann automatisch funktioniert, wenn das betreffende DBMS das unterstützt. Auf die Gefahr hin, mich zu wiederholen:

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.

Automatisch bedeutet hier nicht halbautomatisch, sondern in der Tat ganz automatisch ohne weiteres Zutun. Um jedoch auf einen tatsächlichen Fall, bei dem es nicht wie erwartet ganz automatisch funktioniert, eingehen zu können, wäre es hilfreich, wenn du ein wenig mehr dazu verraten würdest. Ich habe diesen Fall mit den von mir genannten DBMS in vielen Jahren der Datenbankanwendungsentwicklung noch kein einziges Mal erlebt, nicht mal ansaztweise, weder mit Ado, IbDac, dbExpress, FibPlus, Zeos oder UIB. Mit anderen Worten: Meine Ids wurden bislang immer verläßlich erzeugt.

Nachtrag:

Wenn irgendwelche obsolte DBMS hier Fehlverhalten zeigten, sollten sie nicht mehr eingesetzt werden. Insbesondere der Einsatz der völlig veralteten Borland Database Engine sollte, will man zukunftsfähige und zuverlässige DB-Anwendungen entwickeln, unbedingt vermieden werden.

[mse1]

Zitat von Perlsau:

Ich habe diesen Fall mit den von mir genannten DBMS in vielen Jahren der Datenbankanwendungsentwicklung noch kein einziges Mal erlebt, nicht mal ansaztweise, weder mit Ado, IbDac, dbExpress, FibPlus, Zeos oder UIB. Mit anderen Worten: Meine Ids wurden bislang immer verläßlich erzeugt.

ID's werden im Server sicher verlässlich erzeugt. Aber kannst du wirklich die Hand dafür ins Feuer legen, dass *alle* client libraries und Komponenten die erzeugte ID korrekt und im richtigen Moment im Feldinhalt abbilden?
MSEgui z.B. macht dies automatisch für das primary key Feld via "last insert id" wenn die DB es unterstützt. Für andere DB's muss entweder "tsequencelink" verwendet werden oder das Feld-flag "of_refreshinsert" und eventuell "of_refreshupdate" gesetzt werden, welche die "returning" Option im SQL-Kommando aktivieren.