Wie kommt man an die ID des eingefügten Eintrages

[kagi3624]

Zitat von DeddyH:

Versuch mal
aQuery.Open; statt
aQuery.ExecSQL;

THX! Hat funktioniert!

Zitat von DeddyH:

Gibt es das unter ZEOS auch? Ich kenne es so nur bei FireDAC.

Zumindest bei meiner Komponente ging es nicht.

[generic]

Insert Befehle können mehrere Zeilen anlegen und Trigger dann noch mehr.
Es ist immer dann interessant, wenn LAST_INSERT_ID zum Einsatz kommt.
Zum einen wir ja nur eine ID zurück geliefert, auch wenn mehrere Datensätze eingetragen worden sind,
Zum anderen welche ID die vom Hauptdatensatz oder ggf. die letzte ID welche ein Trigger angelegt hat.

Viele SQLs sind um OUTPUT erweitert worden, so dass ein INSERT auch eine Tabelle zurück geben kann.

In PG wird das mit "RETURNING" erreicht:
https://www.postgresql.org/docs/9.5/sql-insert.html

[Sinspin]

Im Regelfall sollte man sein Insert doch so gestalten können das man danach mit einem Select in der Lage ist seinen Datensatz zu finden.
Zudem kennt man seine DB ja wohl so weit das man weis was beim Insert läuft und wieviele Datensätze erzeugt werden.
LastAutoInc ist zum Beispiel auch in FireDac nicht für alle DB implementiert die angesprochen werden können.

[Rollo62]

Zitat von Sinspin:

... das man danach mit einem Select ... LastAutoInc ...

Wenn das in einem 2-schrittigen Prozess, von aussen, gemacht wird,
dann könnte ja in der (Millisekunde) Zwischenzeit Jemand anderes einen neuen Record angelegt haben.
Dann stimmt dein LastAutoInc oder LastRecord nicht mehr.

[DeddyH]

Zumindest MySQL gibt bei last_insert_id() die ID des letzten Datensatzes zurück, der in der aktuellen Verbindung angelegt wurde. In DBMS, die keine Möglichkeit einer RETURNING-Klausel bieten, muss das auch gewährleistet sein, sonst kann man sie ja faktisch nicht gebrauchen.

[hstreicher]

Zitat von kagi3624:

Zitat von Der schöne Günther:

Das RETURNING liefert doch ein Ergebnis, genau wie eine SELECT-Query. Bekommst du da nichts zurück?

Code:

i := zQuery.FieldByName('ID').AsInteger;

Hier wird mir aber gesagt, dass so ein Feld nicht existiert nach dem ausführen des Statements.

ja , es wird ja kein Select ausgeführt also keine Ergebnisswerte zum Abfragen geöffnet

bei IbDac UniDac geht das So
Ii := zQuery.ParambyName('RET_ID').AsInteger;

das "RET_" wird von IBDac hinzugefügt

[Sinspin]

Zitat von Rollo62:

Wenn das in einem 2-schrittigen Prozess, von aussen, gemacht wird,
dann könnte ja in der (Millisekunde) Zwischenzeit Jemand anderes einen neuen Record angelegt haben.
Dann stimmt dein LastAutoInc oder LastRecord nicht mehr.

Sorry. Das ist quatsch.
"von außen machen" : von außerhalb der Transaktion in der man gerade arbeitet wäre es wohl ein bisschen seltsam nach einem autoinc zu fragen.
"LastAutoInc" : ist bei allen DB mit denen ich zu tuen habe Session bezogen, oder kann Session/Active query bezogen abgefragt werden. Bei MSSQL gibt es dafür @@IDENTITY. Was andere DB dafür bereitstellen weis ich nicht. Aber vermutlich ähnliche Lösungen.

[Rollo62]

Zitat von Sinspin:

Zitat von Rollo62:

Wenn das in einem 2-schrittigen Prozess, von aussen, gemacht wird,
dann könnte ja in der (Millisekunde) Zwischenzeit Jemand anderes einen neuen Record angelegt haben.
Dann stimmt dein LastAutoInc oder LastRecord nicht mehr.

Sorry. Das ist quatsch.

Gut zu wissen, es hörte sich für mich so an als ob das Jemand vorhätte

[Sinspin]

Von außen wird das nix. Es sei denn, man kann sich ganz sicher sein das man den Record auch ohne AutoIncwert noch indentifizieren kann.
Zum Beispiel indem man beim Insert eine GUID in den neuen Record schreibt. Die ist ja (fast) Weltweit eindeutig. Geht also zum identifizieren. Allerdings ist son Ding ne ganz schöne Kanone.
Eine Id für den Nutzer plus eine selber hochgezählte Zahl tut es auch. Es gibt zig Möglichkeiten, man muss nur wollen

[Delphi.Narium]

Zeos kennt auch auch noch TZSequence.

Der Komponente weist man die zu nutzende Datenbanksequenz zu.

Vor dem Insert holt man sich dort den nächsten Wert für die ID und übergibt den dann im Insert mit, so dass die Datenbank nicht die ID vergeben muss und man dann auf die Suche gehen muss, welche ID denn da wohl der eingefügte Satz bekommen haben könnte.

Sind in einem ExecSQL mehrere Inserts enthalten, holt man sich entsprechend viele Wert von der TZSequence und weist die dann in den Insertstatements entsprechend zu (Parameter).

Damit hat man dann weder ein Problem beim Ermitteln der ID für jeden der Datensätze, noch kann jemand anderes "quasi von außerhalb der eigenen Transaktion" die Sequenz für andere Aufgaben weiterzählen, so dass man beim Lesen des letzten Wertes der Sequenz dann ggfls. was falsches bekommen könnte (oder sowasinderart).

Für viele Inserts in einem ExecSQL setzt man bei TZSequence BlockSize auf die Anzahl der Inserts und holt dann den nächsten Wert. Damit sind dann dieser Wert plus die nächsten BlockSize - 1 Werte für einen reserviert und für andere nicht mehr vergebbar. Für z. B. 50 Inserts muss man also die Sequenz nicht 50 mal abfragen, sondern nur einmal mit BlockSize 50 und hat damit die nächsten 50 Ids in aufsteigender Folge für sich reserviert.