MySQL Duplicate Entry Auto-Inc

[nahpets]

Ist die 'id' in dem Statement enthalten? Result := Format('INSERT INTO %s (%s) VALUES (%s)',[ClassToTableName(cl),fields,values]); Wenn ja, stelle sicher, dass dem nicht so ist.

Weiß nicht, wie sich MySQL verhält, wenn man für ein Auto-Increment-Feld einen Wert liefert. Nimmt es auf jeden Fall einen eigenen neuen Wert oder übernimmt MySQL dann den "gelieferten" Wert?

Wenn ich Deinen Quelltext richtig verstehe, sollte forceId auf jeden Fall false sein oder für die ID explizit Null geliefert werden.

So in der Art:

Delphi-Quellcode:

if forceId then begin
  fields := fields + sep + '`' + prop.Name + '`';
  values := values + sep + 'Null';
end;

[JRichmann]

Hallo...

das Auto-INC Feld ist NICHT enthalten... es taucht im SQL String nicht auf.
(wenn es enthalten ist und auch gefüllt, dann kommt MySQL nicht klar).

[nahpets]

Wenn also sichergestellt ist, dass die ID nicht vomn Client geliefert wird, kann es nur ein datenbankseitiges Problem sein, eine Fehlersuche in Deinen Quellen dürfte sich damit erübrigen.

Schau mal bitte, ob Du hier weitere Infos findest: https://www.benefind.de/web.php?q=my...icate+Entry%22
Es scheint jedenfalls häufiger ein ähnliches "Problem" zu geben.

[JRichmann]

> kann es nur ein datenbankseitiges Problem sein, eine Fehlersuche in Deinen Quellen dürfte sich damit erübrigen

Ja..... (leider sehe ich das auch so).

Ich denke, schon, dass der Fehler im Code liegt.... Aber nicht so einfach.
Im Kern streikt wohl MySQL (es muss aber irgendwie an der Benutzung von MySQL liegen.... und dann doch wieder am Code)

[jobo]

Zitat von JRichmann:

Hallo...

das Auto-INC Feld ist NICHT enthalten... es taucht im SQL String nicht auf.
(wenn es enthalten ist und auch gefüllt, dann kommt MySQL nicht klar).

Ich sehe jetzt an dem Code nicht, dass das ID Feld ausgeschlossen wird. Im Gegenteil, die "Props" werden dynamisch abgefragt und daraus das Statement gebaut.
Vielleicht doch mit ID, ab und zu?
Oder hast Du die konkreten SQL Statements vorliegen, wenn der Fehler zuschlägt?

[Sir Rufo]

Hat denn jeder Thread auch seine eigene Connection?

Wenn nicht, dann ist das auch kein Wunder mit der doppelten ID Vergabe.

[jobo]

Zitat von Sir Rufo:

Hat denn jeder Thread auch seine eigene Connection?

Wenn nicht, dann ist das auch kein Wunder mit der doppelten ID Vergabe.

Wenn die ID nicht mitgeschickt wird, sondern wirklich von der DB generiert wird, sollte das doch wohl piepegal sein, oder?

ot
ich würde sofort die DB wechseln, wenn es auch nur nach solchen Problemen riecht. Bei diesem System auch aus anderen Gründen. Kann seit einigen Jahren nicht mehr nachvollziehen, warum so häufig oder überhaupt mysql eingesetzt wird.
/ot

[Sir Rufo]

@jobo

Wenn du mit mehr als einem Thread auf die gleiche Session zugreifst dann kann bei jeder DB alles passieren (meistens Grütze).

Jede Session ist an einen Thread gebunden und bei einer vernünftigen Implementierung (dieses Connection-Objekts) würde dir eine Exception um die Ohren fliegen, wenn du mit mehr als einem Thread gleichzeitig darauf zugreifst.

[TRomano]

Damit hast Du vollkommen Recht Sir Rufo (jeder Thread eine Connection), aber Jobo meinte, dass, wenn die ID vom DBMS erzeugt wird, eigentlich nichts passieren sollte.
Das DBMS bekommt über das INSERT-Statement eine Anforderung für eine neue ID (auto increment) und sollte diese auch entsprechend bereit stellen. Was clientseitig passiert ist da erst einmal egal (Threads) ... ist schon komisch, dass das DBMS das irgenwie nicht hinbekommt.

[JRichmann]

Hallo...

>Hat denn jeder Thread auch seine eigene Connection?

Ja

Die DB kann ich leider nicht so einfach wechseln