nicht angemeldet
Hello,
Die Funktion wird wohl ihrerseits auch ein Query (SELECT) an die Datenbank richten. Ggf. nicht über SQL sondern über den Blockbuffer des Request-Interfaces.
so wie ich das sehe, muss man sie in eine SELECT Anweisung einbauen, um den Wert zu erhalten. insofern ruft sie keine SELECT Anweisung auf, sondern ist teil einer SELECT Anweisung.
Das betrifft aber nur die MySQL-Funktion LAST_INSERT_ID()
SELECT last_insert_id()
ermittelt diese und gibt sie in einem Resultset zurück.
Die PHP-Funktion mysql_insert_id() gibt die letzte neu erzeugte Autoincrement-ID direkt zurück, aber nur als INT.
Trotzdem benötigt die Funktion intern einen Request an die Datenbankmaschine.
Außerdem kann die Funktion nur "kurze" AutoIncrements auslesen, also keine 8Byte-Schlüssel (Bigint).
kann sein, ist mir nicht bekannt, ob es da eine einschränkung gibt. in den dokus habe ich es nicht gesehen oder übersehen. das läßt sich aber doch einfach umgehen, wenn es sich nicht um einen datentyp von bigint ist ?
Das Problem ist versteckt:
Man kann inzwischen schon länger Tabellen mit Schlüsseln im BIGINT-Format anlegen. Da wir ja uns ja noch alle gut an das Y2K-Problem erinnern können, wird das auch oft gemacht. Gerade in Tabellen mit sehr dynamischem Datenbestand hat man so länger Ruhe vor dem Overflow.
Wenn man aber BIGINT angelegt und dann ggf. eines Tages auch in Bereich eintritt, dann sollte man auch BIGINT lesen und nicht nur INT. Sonnst stimmen ab diesem Moment plötzlich die Referenzen nicht mehr. Und das wäre hässlich.
Ich habe noch nicht ausprobiert, ob PHP wenigstens einen Fehler auslöst, wenn der INT-Bereich zu Ende ist und ein Carry produziert.
Liebe Grüße aus http://www.braunschweig.de
Tom
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen