SQL Automatisch zugeteilte Id ermitteln.

[supermuckl]

Zitat von p80286:

Zitat von supermuckl:

ich hab das problem letztens in postgres so gelöst:

transaction auf
query ausführen
"id des eingefügten records auslesen" query dahinter
transaction zu

damit kommt direkt die neue id als resultset zurück

Unter Umständen könnte das ja auf allen Datenbanken, egal wieviele Benutzer im Moment zugreifen funktionieren? Und auch noch unabhängig von der eingesetzten Schnittstellensoftware?
Das kann nicht sein!

Gruß
K-H

bin ich mir nicht so ganz sicher
aber es gibt halt den weg - und ob der sicher ist, hängt von der implementation der transaktion ab (transaktionsisolation)

begin;
insert into test(name) values ('something');
select CURVAL('test_id_seq');
commit;

und auch den weg (postgresql native) über
"returning"

INSERT INTO t2 (eid, ...) VALUES (...) RETURNING eid;

ob es das bei anderen DBs gibt, weiß ich nicht

[Mikkey]

@supermuckl

Eine Funktion "CURVAL" dürfte es nicht durchgehend auf allen DBMS geben. Allerdings hatte ich Deinen ersten Beitrag dazu eher so verstanden:

Code:

INSERT INTO table(f1, f2) VALUES(<Schlüsselwert>, 'Blabla');
SELECT <autoincrementfield> FROM table WHERE f1=<Schlüsselwert>

Der Schlüssel muss dann natürlich eindeutig sein.

Das dürfte innerhalb einer Transaktion in jedem DBMS funktionieren, könnte bei manchen (je nach Konfiguration) aber zum Rollback führen, wenn zwei User "gleichzeitig" diese Transaktion durchführen.

[mjustin]

Zitat von Mikkey:

Code:

INSERT INTO table(f1, f2) VALUES(<Schlüsselwert>, 'Blabla');
SELECT <autoincrementfield> FROM table WHERE f1=<Schlüsselwert>

Das dürfte innerhalb einer Transaktion in jedem DBMS funktionieren

Was ist an Stele von <autoincrementfield> denn einzusetzen, das auf jedem DBMS funktioniert?

Code:

SELECT <autoincrementfield> FROM table WHERE f1=<Schlüsselwert>

Wenn das Feld "table.f1" das Primary Key Feld ist, ergibt sich das Problem, dass man den Autonkrementwert nicht kennt, und daher logischerweise auch kein

Code:

SELECT f1 FROM table WHERE f1=<Schlüsselwert>

durchführen kann. Denn <Schlüsselwert> ist bei Autoinkrement-Feldern nicht bekannt (wenn der Wert über einen BEFORE INSERT Trigger unter Verwendung eines Firebird-Generators erzeugt wurde, hat der Client nach Ausführung des INSERT keinen Zugriff auf den soeben erzeugten <Schlüsselwert>).

[supermuckl]

der TE könnte ja mal erzählen, was für eine DB er einsetzt.

//edit
da stehts mysql..

[mkinzler]

Man könnte auch die Frage lesen, den da steht MySQL!!

[arnof]

Zitat von mkinzler:

Man könnte auch die Frage lesen, den da steht MySQL!!

Ich benutze zumeist MYSQL via ADO, da geht das in 95% der Fälle, manchmal aber auch nicht (bugs gibt es überall), dann hilft:

SELECT LAST_INSERT_ID()

[DeddyH]

Womit wir dann wieder bei der allerersten Antwort wären

[Mikkey]

Zitat von mjustin:

Was ist an Stele von <autoincrementfield> denn einzusetzen, das auf jedem DBMS funktioniert?

Natürlich das Feld der Tabelle, in das die erzeugte Zahl eingetragen wird.

Zitat von mjustin:

Wenn das Feld "table.f1" das Primary Key Feld ist, ...

Bitte nichts lesen, was nicht geschrieben wurde!

f1 soll nicht primary Key sein, sondern lediglich eindeutiger Schlüssel.

[Sir Rufo]

Die ganze Diskussion ist doch eigentlich unsinnig, denn

1. Niemand bestreitet, dass ein RDBMS eine ID generieren kann
2. Die Diskussion damit anfing, dass es Provider gab/gibt die es nicht schaffen diese vom RDBMS generierte ID zurück in das DataSet zu liefern.
   

   Beobachtetes Verhalten

   Der Datensatz war korrekt eingetragen, hatte vom RDBMS eine ID zugewiesen bekommen, aber im DataSet war dieser Datensatz immer noch mit leerem ID Feld. Um die ID zu erhalten musste das Dataset neu geladen werden und nun war das große Rätselraten, welcher Datensatz nun der war, der da gerade eingetragen wurde.

Irgendwie dreht sich der Kern dieser Diskussion darum, dass der eine meint, dass der andere meint, dass ein RDBMS keine IDs generiert, was aber niemand bezweifelt (1).

Das Thema geht eigentlich um Punkt (2) und der ist irgendwie nicht Thema der Diskussion ...

Sollte also der Provider es nicht schaffen die von MySQL (das ist das RDBMS dieses Themas) generierte ID zu liefern, dann geht man eben den folgenden Weg:

SQL-Code:

CREATE TABLE `foo` (
  `foo_id`  int NOT NULL AUTO_INCREMENT ,
  `foo_value`  varchar(50) NOT NULL ,
  PRIMARY KEY (`foo_id`) );

Delphi-Quellcode:

LQuery.SQL.Text := 'INSERT INTO foo (foo_value) VALUES (:foo_value); SELECT LAST_INSERT_ID() Foo_ID;';
LQuery.ParamByName('foo_value').Value := 'bar';
LQuery.Open;
LId := LQuery.FieldByName('Foo_ID').Value;

[supermuckl]

richtig!

aber genau das

Code:

LQuery.SQL.Text := 'INSERT INTO foo (foo_value) VALUES (:foo_value); SELECT LAST_INSERT_ID() Foo_ID;';

muss in einer multiuser DB in einer transaktion aufgerufen werden, soweit ich das richtig sehe