nicht angemeldet
@@IDENTITY in mysql???
hallo self gemeinde,
ich würde ganz gern wissen wie ich in mysql den wert einer autoincrement spalte herausfinde, den ein neuer datensatz bekommen würde _bevor_ ich etwas in die datenbank schreibe, bzw. ohne das ich auch danach etwas hineinschreibe....
es muss ja nicht zwangsläufig eine id höher sein als der set davor, weil eventl. zwichendurch einige datensätze gelöscht wurden...
bei ms-SQL gibts dafür den befehl "@@IDENTITY"
ich bin für jeden hinweis dankbar
Stefan
-
Hallo!
ich würde ganz gern wissen wie ich in mysql den wert einer autoincrement spalte herausfinde, den ein neuer datensatz bekommen würde _bevor_ ich etwas in die datenbank schreibe, bzw. ohne das ich auch danach etwas hineinschreibe....
SELECT MAX(auto_inc_spalte)+1 AS neuer_auto_inc_wert FROM tabelle;
es muss ja nicht zwangsläufig eine id höher sein als der set davor, weil eventl. zwichendurch einige datensätze gelöscht wurden...
Das verstehe ich jetzt nicht.
MfG, André Laugks
--
L-Andre @ gmx.de-
hi andré
SELECT MAX(auto_inc_spalte)+1 AS neuer_auto_inc_wert FROM tabelle;
das geht leider nciht weil ebend aus dem grund der unten genannt ist :)
es muss ja nicht zwangsläufig eine id höher sein als der set davor, weil eventl. zwichendurch einige datensätze gelöscht wurden...
Das verstehe ich jetzt nicht.
also nehmen wir das an:
ID | NAME |
--------------
11 | hans |
12 | peter |
13 | blablub |wenn ich jetz den datensatz mit id 13 lösche, dann haben wir:
ID | NAME |
--------------
11 | hans |
12 | peter |wenn ich nun per INSERT n neuen datensatz hinzufüge bekommt der die id 14 _nicht 13_
mfg
Stefan-
Hallo!
das geht leider nciht weil ebend aus dem grund der unten genannt ist :)
wenn ich nun per INSERT n neuen datensatz hinzufüge bekommt der die id 14 _nicht 13_
Dann hast Du nicht das Prinzip einer eindeutigen neuen ID (AUTO_INCREMENT) verstanden und was das für ein Sinn für Datenbank hat.
Du hast für Dein Problem der Spalte den falschen Spaltentyp spezifiziert.
MfG, André Laugks
--
L-Andre @ gmx.de-
Dong!!!!
Jetzt habe ich verstanden was Du möchtest.
Nein, dafür gibt es keine Möglichkeit in MySQL.
MfG, André Laugks
--
L-Andre @ gmx.de
-
-
-
-
Moin!
ich würde ganz gern wissen wie ich in mysql den wert einer autoincrement spalte herausfinde, den ein neuer datensatz bekommen würde _bevor_ ich etwas in die datenbank schreibe, bzw. ohne das ich auch danach etwas hineinschreibe....
Ich habe über Google folgende Diskussion gefunden: http://www.phpbuilder.com/board/showthread.php?threadid=10209766
Die dort gestellte Frage will ich auch dir stellen: Wozu brauchst du das?
Und diese Frage ist durchaus berechtigt, weil davon die Lösung abhängen wird: Entweder geht es, oder es ist Unsinn. Meine derzeitige Meinung tendiert aber zum Unsinn.
Begründung: Das Web ist benutzer-parallel. Es ist also nicht auszuschließen, dass zwei oder mehr Benutzer gleichzeitig die von dir gewünschte Information angezeigt bekommen.
Wenn man sich dieses Szenario durchdenkt, dann kann die Ausgabe der nächsten zu erzeugenden Autoincrement-ID nur bei einem der Benutzer korrekt sein, wenn der weitere Verlauf dazu führt, dass diese ID wirklich benutzt wird. Denn es wäre ja eine Katastrophe, wenn drei Benutzer angezeigt kriegen würden, die nächste ID sei 23, und alle geben dann Daten für diesen Datensatz ein und überschreiben sich beim Speichern gegenseitig.
Ebenso ist es bei solch einem Szenario dann natürlich unsinnig, über ungelegte Eier bzw. Datensätze zu gackern: Nur der, der zuerst speichert, speichert wirklich Datensatz 23 - die anderen beiden speichern Nr. 24 und 25, ohne es vorher zu wissen.
Die im obigen Thread angesprochene Methode, im Single-User-Kontext einen blinden Datensatz anzulegen, der dann logischerweise eine "nächste ID" erhält und dann exklusiv für diesen Benutzer vergeben wird, erscheint mir da sinnvoller. Denn so legt Benutzer 1 den Datensatz 23 an und kann ihn bearbeiten, weitere Benutzer legen Datensatz 24, 25 etc. an. Die einzelne Benutzersession weiß, welcher Datensatz angelegt wurde und kann die eingegebenen Daten dann problemlos speichern. Ja, die Sicherheit vor Manipulationen der Datensatz-ID wäre noch zu klären, aber prinzipiell geht das so. Was allerdings passiert, wenn der Benutzer keinen Datensatz anlegt, wäre noch zu klären. Ohne Benutzerverwaltung, Statuscodes im Datensatz und/oder irgendein Session-Management wird es nicht gehen.
Übrigens: @@IDENTITY macht bei MSSQL genau das, was LAST_INSERT_ID() in MySQL macht. Sicherlich gibts eine Möglichkeit, doch irgendwie den aktuellen Zählerstand herauszufinden (MySQL muß den Wert ja irgendwo verwalten), aber das wäre weitab von vernünftigem SQL und vernünftigem Datenbankdesign.
Zitat von http://www.webmasterworld.com/forum13/1348.htm
I downloaded the SQL server books from msdn and found this description of @@IDENTITY"After an INSERT, SELECT INTO, or bulk copy statement completes, @@IDENTITY contains the last identity value generated by the statement. If the statement did not affect any tables with identity columns, @@IDENTITY returns NULL. If multiple rows are inserted, generating multiple identity values, @@IDENTITY returns the last identity value generated."
Mit anderen Worten: @@IDENTITY gibt dir nur dann einen Wert, wenn durch das SQL-Statement vorher eine ID automatisch generiert wurde, sonst nicht. Und das ist eben immer der Fall, wenn du eine Datenbankverbindung neu herstellst. LAST_INSERT_ID() arbeitet verbindungsbezogen.
- Sven Rautenberg
--
Signatur oder nicht Signatur - das ist hier die Frage!-
was @@identity betrifft, so hast du recht...
ich hatte das in anderer (falscher) erinnerung...nun zu der frage warum ich das brauche:
es wird ein file auf den webserver geladen, dessen url in der datenbank zum zugehörigen datensatz gespeichert wird...das file soll nach möglichkeit im dateinamen die id des datensatzes enthalten um doppelnamen zu vermeiden...
man könnte nat. erst den datensatz in die datenbank schreiben und dann das file kopieren, allerdings kann während des file uploades ein fehler entstehen (unzulässiges file, datenabrruch,...) so das file nicht korrekt hochgeladen wurde, der datensatz steht nun aber schon in der datenbank und man müsste ihn extra nochmal löschen...
was nat. auch kein problem wäre, allerdings hatte ich gedacht das es mit der vorher-id-bekommen methode eleganter wäre
mfg
Stefan-
Moin!
was @@identity betrifft, so hast du recht...
ich hatte das in anderer (falscher) erinnerung...nun zu der frage warum ich das brauche:
es wird ein file auf den webserver geladen, dessen url in der datenbank zum zugehörigen datensatz gespeichert wird...Wahrscheinlich ist dir die richtige Vorgehensweise nur noch nicht eingefallen. :)
Mal konkret überlegt: Wenn du eine Datei, die Bestandteile eines Datensatzes sein soll, hochlädst, dann hast du zwei Möglichkeiten:
a) Datensatz und Datei getrennt übertragen
b) Datensatz und Datei _gemeinsam_ übertragenBei Methode a mußt du, da es sich um zwei getrennte HTTP-Requests handelt, dem einen Request irgendwie mitgeben, dass er einen Bezug zum anderen Request herstellt. Also: Entweder lädst du zuerst die Datei hoch und gibst als erfolgreiche Ergebnisseite eine aus, in der im Formular für die weiteren Datensätze der _temporäre_ Dateiname der erfolgreich hochgeladenen Datei enthalten ist, oder es läuft umgekehrt, und zuerst wird der restliche Datensatz abgefragt, und als Ergebnisseite kommt das Upload-Formular, welches die erzeugte Datensatz-ID enthält, um die Daten dann zuordnen zu können.
Beide Methoden haben ein Problem: Der zweite Request kann scheitern oder einfach nicht stattfinden, weshalb du entweder einen dateilosen Datensatz in der Datenbank hast, oder eine datensatzlose temporäre Datei, die niemals umbenannt wurde.
Deshalb ist es schlauer, die Daten für einen Datensatz in einem einzigen Formular abzufragen. Dann siehst du, ob der Upload geklappt hat und kannst im Fehlerfall entsprechend handeln, und im Erfolgsfall Datensatz und Datei als Einheit speichern.
man könnte nat. erst den datensatz in die datenbank schreiben und dann das file kopieren, allerdings kann während des file uploades ein fehler entstehen (unzulässiges file, datenabrruch,...) so das file nicht korrekt hochgeladen wurde, der datensatz steht nun aber schon in der datenbank und man müsste ihn extra nochmal löschen...
was nat. auch kein problem wäre, allerdings hatte ich gedacht das es mit der vorher-id-bekommen methode eleganter wäre
In Datensatz-IDs entstehen zwansgläufig Lücken. Das ist keine Schande, sondern normal.
- Sven Rautenberg
--
Signatur oder nicht Signatur - das ist hier die Frage!-
Hi Sven
Wahrscheinlich ist dir die richtige Vorgehensweise nur noch nicht eingefallen. :)
Naja, es hat schon irgendwie funktioniert, ich bin nur gerade auf dem Trip der Ver(schlimm)besserung. :)
Deshalb ist es schlauer, die Daten für einen Datensatz in einem einzigen Formular abzufragen. Dann siehst du, ob der Upload geklappt hat und kannst im Fehlerfall entsprechend handeln, und im Erfolgsfall Datensatz und Datei als Einheit speichern.
Die Daten werden bereits in einem Formular erhoben, das Problem war nur die Entscheidung entweder zuerst das File abzuspeichern und danach die Datenbank zu füllen oder umgedreht. Der sicherste Weg, so wir mir scheint, ist zuerst das File zu bearbeiten denn wenn dabei ein Fehler entsteht ist der Datensatz noch nicht gespeichert.
Wie auch immer. Ich habe es jetzt so gelöst, dass zuerst das File gechecked wird, danach der Datensat in MySQL geschrieben und mit last_id die ID ebend dieses Datensatzes ermittelt wird, und ich dann mit Hilfe der ID das File umbenenne/kopiere.
In Datensatz-IDs entstehen zwansgläufig Lücken. Das ist keine Schande, sondern normal.
Da hast du natürlich auch wieder Recht. :)
Danke nochmals für deine Hilfe, sie hat mir ein paar wichtige Denkanstösse gegeben. :)mfg
Stefan
-
-
-