[gelöst]AutoIncrement-Wert beim INSERT ermitteln(geht das?)

[hubblec4]

Wenn ich einen Datenbankeintrag mache,
wird in einer Spalte, welche mit Autoincrement versehen ist, der wert automatisch um jeweils eins erhöht.
(sinn und zwck des autoincrements).

wie kann ich diesen neuen wert direkt ermitteln? (am besten beim INSERT.)

Ich mache das bis jetzt so:
den neuen Eintrag in die datenbank schreiben und dann direkt einen neuen SQL-Befehl mit COUNT(*), welcher mir dann die zahl des letzten eingefügten Eintrags zurückgibt.

Problem an der sache, wenn ich den Eintrag gemacht habe und bis der neue befehl mit dem COUNT(*) startet, könnte ja ein anderer wieder einen Eintrag gemacht haben und ich erhalte die falsche Zahl.

Wie kommt man an den Autoincrementwert der dann auch ganz sicher zu dem Eintrag passt den man gemacht hat?

LG
hubble

[hde]

Das ist von Datenbank zu Datenbank unterschiedlich Schau in die Wilkis der jeweiligen DB

hde

[Thomas B.]

Bei AutoIncrement interessiert normalerweise der Wert beim INSERT nicht. Der Index (Schlüssel) wird erst später z.B. beim Tabellenabgleich gebraucht.

Bei MySQL hilft dir folgender Funktionsinhalt:

Code: Alles auswählen

fSQLQuery.SQL.Clear;
fSQLQuery.SQL.Text := 'SHOW TABLE STATUS WHERE NAME=MeinTabellenName';
fSQLQuery.Open;
fSQLQuery.First;
Result := fSQLQuery.FieldByName('Auto_increment').AsInteger; // Rückgabewert = nächste freie ID
fSQLQuery.Close;
 

Zur Absicherung beim Parallelzugriff mehrerer Clients mit Lock/Unlock arbeiten.

[Patito]

Es kommt wie gesagt auf die Datenbank an.

Bei manche Datenbanken gibt es Id-Generatoren.
Manche Datenbanken haben ein sinnvolles 'SELECT @@identity'.
Manche Datenbanken haben eine eher kaputte Version davon (d.h. sobald Trigger im Spiel sind, gibt es Probleme).
Bei manchen Datenbanken gibt es nichts sinnvolles.

Im Notfall verwenden manche Leute GUIDs (soetwas habe ich vor allem im MS-Umfeld gesehen...).

[Michl]

Ich mache das bis jetzt so:
den neuen Eintrag in die datenbank schreiben und dann direkt einen neuen SQL-Befehl mit COUNT(*), welcher mir dann die zahl des letzten eingefügten Eintrags zurückgibt.

Das halte ich für problematisch. Was passiert, wenn ein Nutzer mal einen Datensatz löscht?!

Es ist möglicherweise nicht die performanteste Lösung, Du könntest nach einem "Insert" mit einem "Select" genau den eingefügten Wert abfragen und erhälst dabei die automatisch generierte ID zurück (falls keine Dopplungen erlaubt sind).

[Antrepolit]

Wenn ich einen Datenbankeintrag mache,
wird in einer Spalte, welche mit Autoincrement versehen ist, der wert automatisch um jeweils eins erhöht.
(sinn und zwck des autoincrements).

wie kann ich diesen neuen wert direkt ermitteln? (am besten beim INSERT.)

Ich mache das bis jetzt so:
den neuen Eintrag in die datenbank schreiben und dann direkt einen neuen SQL-Befehl mit COUNT(*), welcher mir dann die zahl des letzten eingefügten Eintrags zurückgibt.

Problem an der sache, wenn ich den Eintrag gemacht habe und bis der neue befehl mit dem COUNT(*) startet, könnte ja ein anderer wieder einen Eintrag gemacht haben und ich erhalte die falsche Zahl.

Wie kommt man an den Autoincrementwert der dann auch ganz sicher zu dem Eintrag passt den man gemacht hat?

LG
hubble

1. Mache ein SELECT MAX(id) statt COUNT, dann passt das auch.
2. Falls da wirklich zwei Leute zeitgleich Schreiben, solltest du unbedingt mit Transaktionen und Isolation Levels arbeiten um Chaos zu verhindern.

[hubblec4]

ja das mit dem count(*) habe ich dann auch als nicht gut empfunden. (löschen geht so in dem sinne nicht)

das nochmalige abrufen mit dem vergleich der zuletzt eingetragenen daten könnte unter umständen auch nicht gehen, wegen doppelungen.

ich denke das mit MAX(id) ist ausreichend, da jetzt sicher keine flut von einträgen kommen wird.

danke für die hilfe.

[Patito]

ja das mit dem count(*) habe ich dann auch als nicht gut empfunden. (löschen geht so in dem sinne nicht)
das nochmalige abrufen mit dem vergleich der zuletzt eingetragenen daten könnte unter umständen auch nicht gehen, wegen doppelungen.
ich denke das mit MAX(id) ist ausreichend, da jetzt sicher keine flut von einträgen kommen wird.

danke für die hilfe.

Sorry, aber Hilfe würde ich das jetzt nicht nennen. Man sollte noch mal deutlich betonen, dass egal, ob Du Max(),
Count() oder einen Zufallswert nimmst, das so im Multi-User-Betrieb nicht funktioniert.

Wenn Du keinen Mechanismus nimmst, der von der Datenbank bereitgestellt wird (Locks, @@identity, Sequence-Generatoren, ...),
zerbröselt Dir das ganze irgendwann.

Benutz einen Mechanismus, der zu deiner Datenbank passt! Und bau keinen Scheiß...

[hubblec4]

recht hast du auf jedenfall keine frage.

ich habe hier eine MySQL5.1 DB vorliegen. Werde ich mich mal bei denen auf der seite durchwühlen wie das genau zu machen ist.

[Antrepolit]

recht hast du auf jedenfall keine frage.

ich habe hier eine MySQL5.1 DB vorliegen. Werde ich mich mal bei denen auf der seite durchwühlen wie das genau zu machen ist.

Ich hab dir das Stichwort genannt: Isolation Level und READ-COMMITED. Details dazu hier: http://dev.mysql.com/doc/refman/5.1/de/ ... ation.html

[mschnell]

Das ist von Datenbank zu Datenbank unterschiedlich Schau in die Wilkis der jeweiligen DB

Es wäre doch schade, wenn Zeos so etwas allgemein verwendbares nicht vereinheitlichen könnte ...

-Michael

[Patito]

recht hast du auf jedenfall keine frage.

ich habe hier eine MySQL5.1 DB vorliegen. Werde ich mich mal bei denen auf der seite durchwühlen wie das genau zu machen ist.

Ich hab dir das Stichwort genannt: Isolation Level und READ-COMMITED. Details dazu hier: http://dev.mysql.com/doc/refman/5.1/de/ ... ation.html

Ich kenne mich mit MySQL nicht aus. Kann sein, dass es funktioniert.
Aber bei einem Isolation Level Read-Commited würde ich jetzt erwarten, dass man verloren hat,
wenn jemand im Zeitraum zwischen Insert und Select Max() ein Dutzend Inserts komplett fertig commitet?!

[hde]

http://dev.mysql.com/doc/refman/5.1/de/ ... ement.html

[Patito]

Das ist von Datenbank zu Datenbank unterschiedlich Schau in die Wilkis der jeweiligen DB

Es wäre doch schade, wenn Zeos so etwas allgemein verwendbares nicht vereinheitlichen könnte ...

Ein Problem ist, dass das Problem bei verschiedenen Datenbanken mit ganz anderen Mitteln gelöst wird
- Sequenz-Generator
- Autoincrement
- bei manchen Datenbanken stellt man den Key auf GUIDs um

Die beste Lösung ist in jeder Datenbank eine andere und erfordert ggf. Änderungen am Datenbank-Design, sowas kann
eine Client-Library wie Zeos nicht allgemein lösen.

MS-SQL hat z.B. für diese Aufgaben @@IDENTITY, IDENT_CURRENT und SCOPE_IDENTITY, und alle drei funktionieren
nur unter speziellen Bedingungen. Daher habe ich in solchen Datenbanken immer sehr viele GUIDs gesehen...

Bei Datenbanken ist jenseits von "SELECT * FROM Table" Schluß mit der Kompatibilität und spätestens wenn man Inserts
macht ist der Spass mit der Portabilität vorbei.

[mse]

Das ist von Datenbank zu Datenbank unterschiedlich Schau in die Wilkis der jeweiligen DB

Es wäre doch schade, wenn Zeos so etwas allgemein verwendbares nicht vereinheitlichen könnte ...

MSEgui verwendet "LASTINSERTID" oder die "RETURNING" Option beim SQL-statement um die Feldwerte automatisch aufzufrischen. Soviel ich weiss macht ZEOS das inzwischen auch so. Für FPC SQLdb ist "LASTINSERTID" AFAIK ebenfalls implementiert, möglicherweise ohne automatische Feldwertauffrischung, da bin ich nicht sicher.