SQL Automatisch zugeteilte Id ermitteln.

[mjustin]

Zitat:

Zitat von Mikkey (Beitrag 1265464)

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 :D mysql..

[mkinzler]

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

[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

[mkinzler]

Eher 3) Ob man davon ausgehen kann, das der Datensatzzeiger im DataSet auf dem neuen Datensatz steht

[Sir Rufo]

Zitat:

Zitat von supermuckl (Beitrag 1265476)

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

Nein, muss es eben nicht ...

http://dev.mysql.com/doc/refman/5.1/de/information-functions.html

• LAST_INSERT_ID(), LAST_INSERT_ID(expr)
  Gibt den ersten automatisch erzeugten Wert zurück, der für eine AUTO_INCREMENT-Spalte durch die aktuelle INSERT- oder UPDATE-Anweisung eingestellt wurde, die eine solche Spalte modifiziert hat.
  
  Code:

  mysql> SELECT LAST_INSERT_ID();
          -> 195

  Die erzeugte Kennung wird auf dem Server verbindungsspezifisch gehandhabt: Der von der Funktion an einen bestimmten Client zurückgegebene Wert ist der erste AUTO_INCREMENT-Wert, der für die zuletzt abgesetzte Anweisung, die eine AUTO_INCREMENT-Spalte betraf, von diesem Client erzeugt wurde. Dieser Wert darf nicht von anderen Clients bearbeitet werden, auch wenn diese selbst AUTO_INCREMENT-Werte erzeugen. Dieses Verhalten gewährleistet, dass jeder Client seine eigene Kennung abrufen kann, ohne die Aktivitäten anderer Clients berücksichtigen oder Sperren setzen bzw. Transaktionen verwenden zu müssen.
  
  Der Wert von LAST_INSERT_ID() wird nicht geändert, wenn Sie die AUTO_INCREMENT-Spalte eines Datensatzes auf einen „nichtmagischen“ Wert (d. h. einen Wert, der nicht NULL und nicht 0 ist) setzen.
  
  Wichtig: Wenn Sie mehrere Datensätze mithilfe einer einzelnen INSERT-Anweisung einfügen, gibt LAST_INSERT_ID() nur denjenigen Wert zurück, der für den ersten eingefügten Datensatz erzeugt wurde. Grund hierfür ist, dass es möglich sein soll, dieselbe INSERT-Anweisung problemlos auf einem anderen Server zu reproduzieren.

[Mikkey]

Zitat:

Zitat von mjustin (Beitrag 1265467)

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:

Zitat von mjustin (Beitrag 1265467)

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]

Zitat:

Zitat von mkinzler (Beitrag 1265477)

Eher 3) Ob man davon ausgehen kann, das der Datensatzzeiger im DataSet auf dem neuen Datensatz steht

Nein, nach dem Post steht der Datensatzzeiger auf dem neuen Datensatz, weil er da durch das Append schon steht und durch das Post nicht weiterbewegt wird. Allerdings kann es bei einigen Providern passieren, dass diese die generierte ID dort nicht zurück liefern und eben besagte AutoIncrement-Spalte leer ist.

[supermuckl]

" jeder Client seine eigene Kennung abrufen kann, ohne die Aktivitäten anderer Clients berücksichtigen oder Sperren setzen bzw. Transaktionen verwenden zu müssen."

ok das war mir neu. danke!

da arbeitet jede DB etwas anderst :)