SQL Automatisch zugeteilte Id ermitteln.

[Perlsau]

Zitat:

Zitat von mse1 (Beitrag 1265428)

ID's werden im Server sicher verlässlich erzeugt.

Sag ich doch ständig!

Zitat:

Zitat von mse1 (Beitrag 1265428)

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?

Keine Ahnung, was du mit "korrekt" meinst bzw. wie eine inkorrekte Darstellung (Abbildung) aussehen könnte.

Wann ist der "richtige Moment"?

Zitat:

Zitat von mse1 (Beitrag 1265428)

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.

MSEgui? This page was last modified on 12 December 2013, at 12:39

Bis jetzt hat hier noch keiner eine Situation beschrieben, in der die Zuverlässigkeit der Erzeugung einer Id nicht gewährleistet wäre. Ich lese immer nur Andeutungen und "von früher".

Übrigens: Weder Hände noch andere Extremitäten sollte man ins Feuer legen, auch nicht, um irgend etwas zu beweisen. Ich bin nicht dafür haftbar zu machen, wenn irgend jemand eine Konstruktion zusammenbastelt, die irgendwelche fehlerhafte PK-Ids liefert oder anzeigt. Ich hatte damit wie bereits erähnt noch niemals auch nur das geringste Problem. Da gibt's im Zusammenhang mit Datenbank-Anwendungen ganz andere Dinge, die problematisch sein können.

[mkinzler]

Das es bisher und jetzt funktioniert ist aber keine Garantie, dass es auch in der Zukunft so funktioniert. Deshaln würde ich den dokumentierten Weg über die vom DBMS bereitgestellten Funktionen gehen.

[Blup]

Abseits des eigentlichen MySql-Themas:

Zitat:

Zitat von Perlsau (Beitrag 1265386)

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.

Das ist so nicht ganz richtig.
Auch der BeforeInsert-Trigger der Datenbank wirkt erst, nachdem der Datensatz per Post an den Server übergeben wurde.
Es gibt allerdings Komponenten die den Wert solcher Spalten selbst vorab erzeugen.
Dafür muss dann der für diese Spalte zuständigen Generator angegeben werden.
Die Komponente erzeugt die neue ID über eine interne Abfrage und setzt dabei den Generator hoch:

Code:

select GEN_ID(GEN_ZUSATZKLASSE_ID, 1) from RDB$DATABASE

Dann wirkt aber auch der Trigger nicht mehr, da die Spalte bereits belegt ist.

Es ist dagegen fahrlässig, den Generator nur abzufragen ohne den Generatorwert hochzusetzen und sich darauf zu verlassen, dass der Trigger diese ID beim nächsten Post vergibt.
Generatoren zählen für alle Transaktion und Datenbankverbindungen. Bis zum eigenen Post kann sich der Generatorwert schon wieder geändert haben und der Trigger vergibt eine andere ID.

[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

[mse1]

Zitat:

Zitat von Perlsau (Beitrag 1265430)

MSEgui? This page was last modified on 12 December 2013, at 12:39

http://sourceforge.net/projects/mseide-msegui/

Zitat:

Bis jetzt hat hier noch keiner eine Situation beschrieben, in der die Zuverlässigkeit der Erzeugung einer Id nicht gewährleistet wäre. Ich lese immer nur Andeutungen und "von früher".

Das mögliche Problem ist nicht das Erzeugen der ID sondern wie man die erzeugte ID unverzüglich zurück erhält.

[p80286]

Zitat:

Zitat von supermuckl (Beitrag 1265437)

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!:mrgreen:

Gruß
K-H

[Perlsau]

Zitat:

Zitat von Blup (Beitrag 1265435)

Das ist so nicht ganz richtig. Auch der BeforeInsert-Trigger der Datenbank wirkt erst, nachdem der Datensatz per Post an den Server übergeben wurde.

Der Generator – und ich schreibe hier wieder ausschließlich über Firebird, auch wenn ich meine, daß es sich hier um eine generelle Verfahrensweise bei allen modernen DBMS handelt – incrementiert bei BeforeInsert vor dem Posten. In die jeweilige Spalte wird dieser Wert natürlich erst nach dem Posten eingetragen:

This database also maintains a generator named EMP_NO_GEN and a Before Insert trigger named SET_EMP_NO on the EMPLOYEE table, to produce a value for this key whenever a new row is inserted. (Helen Borrie: The Firebird Book)

Wenn die Aktion (insert) nicht abgeschlossen (post) wird (was einem cancel entspricht), setzt der Trigger den einmal erhöhten Generatorwert wieder zurück (rollback):

Work performed by triggers will be rolled back if the transaction that prompted them is rolled back. (Helen Borrie: The Firebird Book)

Zitat:

Zitat von Blup (Beitrag 1265435)

Es gibt allerdings Komponenten die den Wert solcher Spalten selbst vorab erzeugen.
Dafür muss dann der für diese Spalte zuständigen Generator angegeben werden.
Die Komponente erzeugt die neue ID über eine interne Abfrage und setzt dabei den Generator hoch:

Code:

select GEN_ID(GEN_ZUSATZKLASSE_ID, 1) from RDB$DATABASE

Dann wirkt aber auch der Trigger nicht mehr, da die Spalte bereits belegt ist.

Verwechselst du da nicht was? Die Id-Spalte des neu anzulegenden Datensatzes wird erst nach dem Post belegt. Würden die DB-Komponenten den Generatorwert von sich aus hochsetzen, würde das bedeuten, daß der Generatorwert immer um 2 erhöht wird, wenn BeforeInsert oder AfterInsert in der DB gesetzt sind, denn der Trigger wird ja auch ohne entsprechende DB-Komponenten im Client allein schon durch den Insert-Befehl ausgelöst, z.B. wenn ich ein SQL-Script mit Insert-Befehlen laufen lasse.

Zitat:

Zitat von Blup (Beitrag 1265435)

Es ist dagegen fahrlässig, den Generator nur abzufragen ohne den Generatorwert hochzusetzen und sich darauf zu verlassen, dass der Trigger diese ID beim nächsten Post vergibt. Generatoren zählen für alle Transaktion und Datenbankverbindungen. Bis zum eigenen Post kann sich der Generatorwert schon wieder geändert haben und der Trigger vergibt eine andere ID.

Richtig! Für Single-User-Anwendungen spielt das jedoch keine Rolle, bei Multi-User-Anwendungen dagegen schon: Hier sollte man einfach die Id, die nach dem Posten vergeben wurde, aus der jeweiligen Id-Spalte der gerade bearbeiteten Tabelle auslesen. Sollte es irgend eine Spalte in der jeweiligen Systemtabelle geben, die diese LAST_INSERT_IDs protokolliert, besteht dasselbe Problem in einer Multi-User-Umgebung: die letzte eingefügte Id muß nicht zwangsläufig diejenige sein, die der Client eigentlich abrufen möchte – es sei denn, man verwaltet das selbst und hinterlegt in einer weiteren Spalte die entsprechende User-Id.

[supermuckl]

Zitat:

Zitat von p80286 (Beitrag 1265450)

Zitat:

Zitat von supermuckl (Beitrag 1265437)

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!:mrgreen:

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

[mse1]

Zitat:

Zitat von Perlsau (Beitrag 1265458)

This database also maintains a generator named EMP_NO_GEN and a Before Insert trigger named SET_EMP_NO on the EMPLOYEE table, to produce a value for this key whenever a new row is inserted. (Helen Borrie: The Firebird Book)

Wenn die Aktion (insert) nicht abgeschlossen (post) wird (was einem cancel entspricht), setzt der Trigger den einmal erhöhten Generatorwert wieder zurück (rollback):

Work performed by triggers will be rolled back if the transaction that prompted them is rolled back. (Helen Borrie: The Firebird Book)

Leider ist das für Sequenz-Werte nicht möglich:

Zitat:

As said, generators live outside of transaction control. This simply means you cannot safely “rollback” generators inside a transaction. There may be other transactions executing at the same time that change the value while your transaction runs. So once you have requested a generator value, consider it as “gone forever”.

http://www.firebirdsql.org/manual/ge...de-basics.html

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