DB Fehler Warning:#1264

[whitedogs]

Habe folgendes Problem,der User Beantragt Auszahlung mit der Kontonummer 4214****** aber im Adminbereich kommt die Kontonummer 2147483647 an.Wenn ich das in der DB ändern will bekomme ich folgende Meldung

Betroffene Datensätze: 0
Warning: #1264 Out of range value adjusted for column 'kontonummer' at row 1

SQL-Befehl:        UPDATE  `usr_web58_1`.`auszahlung`  SET  `kontonummer`  =  '4214******' WHERE  `auszahlung`.`id`  =30 LIMIT 1 ;

Es gibt diese Kontonummer schon in der DB von einem anderen User ob es da auch Falsch übertragen wurde kann ich nicht sagen.

Wie bekomm ich das hin das er die richtige Kontonummer überträgt.Wenn ich das selbst Teste mit meiner Kontonummer überträgt er alles Ordentlich.Habe es auch mit dieser Kontonummer von diesem User Probiert und da überträgt es wieder Falsch.

 

[transversalis]

Ist Deine Spalte vom Typ INTEGER ? Dann ist 2147483647 leider der Höchstwert, der abgespeichert werden kann. Verwende DECIMAL oder CHAR.

( Wertebereich für 4-Byte binär gepackte Zahlen:
-2147483648 bis +2147483647 )

 

[theHacker]

Verwende [...]CHAR

Was willst du bitte mit CHAR ?! CHAR is für Zeichenketten, nicht für Zahlen. Du kannst BIGINT stattdessen verwenden, der hat Wertebereichgröße 2[sup]64[/sup].
Infos: https://dev.mysql.com/doc/refman/5.1/de/numeric-type-overview.html

 

[transversalis]

Was willst du bitte mit CHAR ?! CHAR is für Zeichenketten, nicht für Zahlen

Richtig, aber mit einer Kontonummer werde ich niemals rechnen. Also spricht nichts dagegen, dieses als Zeichenkette zu interpretieren anstatt als Zahl.

Aber Du hast recht, BIGINT ist die bessere Alternative, sofern sein DB-System das unterstützt

 

[whitedogs]

So hier mal der ausschnitt von der Kontonummerzeile

 

[theHacker]

Richtig, aber mit einer Kontonummer werde ich niemals rechnen. Also spricht nichts dagegen, dieses als Zeichenkette zu interpretieren anstatt als Zahl.

Das stimmt im Prinzip ja auch. Wenn ich aber an die Programmierskills der Leute denke, die diese Scripte bearbeiten, sollte man denen nicht noch zusätzlich die Arbeit aufhalsen, zu prüfen, ob die Kontonummer wirklich ne Kontonummer is, drum hätte ich hier gleich den Integertyp bevorzugt empfohlen.

 

[transversalis]

So hier mal der ausschnitt von der Kontonummerzeile

Ja, INT = INTEGER -> zu klein sh. Wertebereich oben.
Dir wird nicht anderes übrigbleiben, als die Tabelle neu anzulegen und die kontonummer BIGINT zu machen ( oder DECIMAL, wenn Dein DB-System BIGINT nicht unterstützt ).

 

[theHacker]

INT => BIGINT müsste die DB aber konvertieren können

 

[transversalis]

INT => BIGINT müsste die DB aber konvertieren können

das hängt vom verwendeten Datenbanksystem und der Version ab.

( DB2 UDB for z/OS kann ab Version 8 NFM numerische Typen vergrössern , DB2 UDB for AIX Version 8 z.B. kann nur CHAR-Strings vergrössern )

 

[whitedogs]

INT => BIGINT müsste die DB aber konvertieren können

Vielen Dank,habs einfach von INT auf BIGINT gestellt und klappte wunderbar.Die Kontonummer wird nun auch richtig übermittelt.

 

[DaPhreak]

Was willst du bitte mit CHAR ?! CHAR is für Zeichenketten, nicht für Zahlen. Du kannst BIGINT stattdessen verwenden, der hat Wertebereichgröße 2[sup]64[/sup].

Auch wenn ich auch generell ein Verfechter dessen bin, Werte mit korrektem Datentyp zu speichern, will ich hier nur mal vorsichtig warnen: Nicht alles, was auf den ersten Blick eine Zahl ist, sollte auch als Zahl gespeichert werden.

Beim Beispiel Hausnummer kommt man noch schnell drauf, da gibt's halt nicht nur 1,2,3,4 sondern auch 7b.

Auch Postleitzahlen würde ich nicht als Zahl speichern. Da erfasst man die führenden Nullen nicht, eine Eingabe von 09353 wird eben nur als 9353 gespeichert. Klar kann man beim Ausgeben mit %05d arbeiten, nur ob man da auch immer dran denkt? Und wenn man dann vielleicht doch mal ausländische Postleitzahlen erfassen möchte, geht's gleich ganz schief, denn die enthalten oft Buchstaben (Bsp.: GB). Es gibt einige renommierte Seiten, die den Fehler gemacht haben, sowas fällt halt nicht gleich auf.

Telefonnummern sind diskutierbar. Auch hier ist auf führende Nullen zu achten, aber das lässt sich regeln, indem man die Vorwahl separat ablegt.

Bei Kontonummern dürfte es noch okay sein. Es gibt zwar auch dort welche mit führenden Nullen, aber soweit ich weiß, kann man die weglassen. Allerdings muss die glaube ich wenigstens sechsstellig sein, ein %06d wäre also hier schon debattierbar.

Das soll natürlich nicht heißen, dass man auf Ints generell verzichten soll, ganz im Gegenteil. Da wo Integers Sinn machen, sollte man sie auf jeden Fall verwenden, dann aber auch auf die korrekte Dimensionierung achten. Und das hat bei MySQL wirklich nur mit dem Datentyp (SMALLINT/INT/BIGINT) zu tun und nicht mit dem "Länge"-Parameter (INT(11)), mich hat das anfänglich kurz verwirrt.