MySQL Update

[TypischeFrage]

Servus!

ich hab grad einen komischen Fehler:

Ich habe mehrere Teilquerys, die ich mit multi_query von mysqli zusammen ausführe. Läuft eine dieser Teilquerys schief wird Valid auf false gesetzt und der entsprechende commit am ende durch ein rollback() ersetzt. So Weit so gut.

Hier sind zwei Beispielteilquerys:

UPDATE items SET wos = '000311854900006' WHERE itemID = '21'
UPDATE itemdates SET PublicationMonth = 'NOV' WHERE itemID = '21'

Hierbei funktioniert die obere nicht, die untere schon. Das heißt, wenn ich nach dem Ablauf des Scripts in der Datenbank nachschaue, ist NOV richtig eingetragen für die itemID 21 bei PublicationMonth, allerdings ist bei wos nicht die oben zu sehende Nummer eingetragen, sondern immer "2147483647". Egal welche Datensets ich durchlaufen lasse, dort ist immer "2147483647" eingetragen, obwohl in diesem Fall dort '000311854900006' stehen müsste.

Wie gesagt werden mit multi Query erst alle Teilquerys abgearbeitet und danach geguckt, ob $Valid noch true ist, wenn ja commit, wenn nein rollback. Woran kann sowas liegen?

Ich hab durch die kompletten einztragenden Daten durchgeguckt und nirgendswo auch nicht mit STRG + F die Folge "2147483647" gefunden...

Auszüge aus dem Code:

if($Data['Key'] == "Published.BiblioDate" and $Data['Context'] == "source") {  
				     // Publication Month is Splitted[0] and Publication Day Splitted[1]  
				     $Splitted = explode(" ",$Data['Value']);  
					$Query[] = "UPDATE itemdates SET PublicationMonth = '$Splitted[0]' WHERE itemID = '$itemID'";  
					$Query[] = "UPDATE itemdates SET PublicationDay = '$Splitted[1]' WHERE itemID = '$itemID'";  
				}

if($Data['Key'] == "UT") {  
			          // Insert the WOS ID  
			          $Query[] = "UPDATE items SET wos = '" . $Data['Value'] . "' WHERE itemID = '$itemID'";  
				}

$Result = $this->Connect->multi_query($Query);  
				if($Result !== false) {  
			     	// Query was ok - got result  
             			while ($this->Connect->more_results() && $this->Connect->next_result());  
				}  
         			else {  
         		     	// If the query failed  
         		     	$this->Valid = false;  
					$this->SQLErrors[] = $this->Connect->error;  
					return false;  
				}

Vielen Dank für Ideen woran sowas liegt!

[dedlfix]

Tach!

UPDATE items SET wos = '000311854900006' WHERE itemID = '21'
für die itemID 21 bei PublicationMonth, allerdings ist bei wos nicht die oben zu sehende Nummer eingetragen, sondern immer "2147483647".

Welchen Typ hat das Feld wos?

dedlfix.

[TypischeFrage]

Welchen Typ hat das Feld wos?

Hallo,

das Feld 'wos' war int(10), bis mir aufgefallen ist, dass die einzutragenden Werte ja größer sind. Dann habe ich es vorsichtshalber zu int(20) geändert. Allerdings sind in allen wos Feldern auch nachdem ich es zu int(20) geändert habe immer nur die Folgen "2147483647" zu finden.

[Matthias Apsel]

Om nah hoo pez nyeetz, TypischeFrage!

das Feld 'wos' war int(10), bis mir aufgefallen ist, dass die einzutragenden Werte ja größer sind. Dann habe ich es vorsichtshalber zu int(20) geändert. Allerdings sind in allen wos Feldern auch nachdem ich es zu int(20) geändert habe immer nur die Folgen "2147483647" zu finden.

und ist denn 0815 eine gültige Integerzahl?

Matthias

[TypischeFrage]

und ist denn 0815 eine gültige Integerzahl?

Ich bin mir nicht ganz sicher was du mir damit sagen willst?

[dedlfix]

Tach!

das Feld 'wos' war int(10), bis mir aufgefallen ist, dass die einzutragenden Werte ja größer sind. Dann habe ich es vorsichtshalber zu int(20) geändert. Allerdings sind in allen wos Feldern auch nachdem ich es zu int(20) geändert habe immer nur die Folgen "2147483647" zu finden.

Integer hat einen festen Wertebereich von minus Irgendwo bis plus Irgendwo, oder 0 bis plus Irgendwo bei einem als unsigned gekennzeichneten Feld. Die Zahl in Klammern gibt nur die Breite der Ausgabe an, was aber auch nur an der Konsole von Bedeutung ist. Nur bei DECIMAL wäre die Länge auch für den speicherbaren Wert entscheidend.

dedlfix.

[Sven Rautenberg]

Moin!

das Feld 'wos' war int(10), bis mir aufgefallen ist, dass die einzutragenden Werte ja größer sind. Dann habe ich es vorsichtshalber zu int(20) geändert. Allerdings sind in allen wos Feldern auch nachdem ich es zu int(20) geändert habe immer nur die Folgen "2147483647" zu finden.

Die Längenangabe bei Nummerntypen dient nur der Formatierung mit führenden Nullen (dann, wenn das Feld "zerofill" hat), ansonsten ist es irrelevant. Der speicherbare Wertebereich ändert sich dadurch nicht.

Wenn du größere Werte als INT speichern willst, musst du BIGINT nehmen und drauf achten, dass PHP ggf. mit solch großen Zahlen Probleme hat.

Oder du speicherst als String, dann kannst du sicher sein, dass z.B. auch alle führenden Nullen erhalten bleiben.

- Sven Rautenberg

[Der Martin]

Servus!

ich hab grad einen komischen Fehler:

Hi,

UPDATE items SET wos = '000311854900006' WHERE itemID = '21'

nachdem du im nächsten Post ergänzt hast, dass das ein Integer-Feld ist, war meine erste Eingebung: Eine Oktalzahl kann nie und nimmer die Ziffer 8 enthalten. Dann habe ich nachgeforscht und dabei erfahren, dass mySQL keine Oktal-Notation kennt. Also muss die Darstellung trotz der führenden Null als Dezimalzahl interpretiert werden.

[...] dort ist immer "2147483647" eingetragen

Und die Tatsache, dass das exakt 2³¹-1 ist, sollte einem eigentlich zu denken geben. Sieht also so aus, als ob mySQL Integer-Werte nur mit 32bit speichert, den zu großen Zahlenwert erkennt und ersatzweise den größten darstellbaren Wert in das Feld einträgt.

obwohl in diesem Fall dort '000311854900006' stehen müsste.

Nein. Die führenden Nullen sind nur Zierat bei der Ein- oder Ausgabe. Wenn Integers mit 64bit gespeichert würden, stünde in diesem Feld der Wert 311854900006.

// Publication Month is Splitted[0] and Publication Day Splitted[1]

Btw, das Partizip von 'split' ist ebenfalls 'split'. Es gibt im Englischen kein 'splitted'.

So long,
 Martin