[SOLUCIONADO] warning #1264 out of range value for column

[Jlopez2014]

Hola a todos... mi inquietud de hoy trata sobre esta linea de error que me manda mysql (warning #1264 out of range value for column 'telcontacto' at row 1) cuando trato de introducir el numero de celular en esa celda... y aunque es de tipo entero 20 no acepta numeros de diez digitos con numero inicial 3... es decir, aqui en colombia los celulares inician 300429xxxx, de diez digitos, y pues la tabla acepta solamente que inicie hasta con 2 (2147483647; celulares que no existen aca obviamente)... que podria ser?, GRACIAS

[quimfv]

Que tipo de campo estas usando

Intenta introducir 2999999999 tampoco te lo permitirá....

Para un numero de telefono usa VARCHAR(10). Si agun dia tienes que entrar telefonos que empiecen por 0 (cero a la izquierda) tendrias problemas con todos los formatos numéricos.

out of range estas entrando un valor mayor al admitido por el tipo de datos usado.

Pero para numeros de telefono el formato adecuado es un tipo string no numérico. En realidad no es un numero es un codigo, y puede tener 0 a la izquierda o por que no en un futuro letras....

[Jlopez2014]

Dale, ya estaba considerando esa opción, más quería confirmar que pasaba en ese caso que me llamó mucho la atención... Gracias por tu colaboración y el campo es de tipo INT (20)...

[gnzsoloyo]

Los números de teléfono, por convención, no se almacenan en columnas numéricas, sino de caracteres. No se hace como numérico porque eso excluye los códigos de DD (discado directo), que comienzan con cero... cosa que como recordarás, no existe en un número.

Por otro lado, el tema del "out of range" usualmente se da cuando se diseña mal la tabla, y se ha usado una columna con signo, cosa que reduce el rango de representación a la mitad.

Postea el CREATE TABLE de la tabla, para que verifiquemos que lo estés haciendo bien. A partir de alli veremos qué te conviene.

Si no sabes como obtenerlo, usa:

Código MySQL:

SHOW CREATE TABLE nombreDeTuTabla
 

donde "nombreDeTuTabla" es el nombre de la tabla en cuestión.

Luego posteanos el resultado completo de esa query.

Por cierto,

INT (20)

eso no significa que pueda aceptar números de hasta 20 dígitos. Se usa para otra cosa.
Un INT con signo sólo puede representar hasta el 2147483647.

Leer el manual de referencia, por favor: http://dev.mysql.com/doc/refman/5.0/...ric-types.html

[Jlopez2014]

Disculpa mi poca agilidad en phpmyadmin, pero no puedo ver toda la información del SHOW CREATE TABLE, pues me la coloca en una pequeña celda y no se ve todo... más mi tabla (empresas) está organizada así: idempresa (varchar 75), nomempresa (varchar 75), direccion (varchar 30), telefono (int 20), email (varchar 70), nomcontacto (varchar 50) y telcontacto (int 30)... no se si de esta forma sea suficiente para analizar la tabla...

[gnzsoloyo]

No me interesan las descripciones. Las descripciones siempre omiten información relevante.
Necesitamos la definición exacta del CREATE TABLE.
Fíjate que en el phpMyadmin tienes una "T" mas o menos así:

<--T-->

Eso expande la salida para mostrarte todo.

Usala y copia lo que te devolvió.

[Jlopez2014]

Listo!... esto es lo que arrojó la consulta:

Código MySQL:

CREATE TABLE `empresas` (  `idempresa` varchar(75) COLLATE utf8_unicode_ci NOT NULL,  `nomempresa` varchar(75) COLLATE utf8_unicode_ci NOT NULL,  `direccion` varchar(30) COLLATE utf8_unicode_ci NOT NULL,  `telefono` varchar(10) COLLATE utf8_unicode_ci NOT NULL,  `email` varchar(70) COLLATE utf8_unicode_ci NOT NULL,  `nomcontacto` varchar(50) COLLATE utf8_unicode_ci NOT NULL,  `telcontacto` varchar(10) COLLATE utf8_unicode_ci NOT NULL,  PRIMARY KEY (`idempresa`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
 

[Jlopez2014]

Perdon, esta linea es cuando cambie los campos de telefono y telcontacto de INT a VARCHAR... esta es la original...

Código MySQL:

CREATE TABLE `empresas` (  `idempresa` varchar(75) COLLATE utf8_unicode_ci NOT NULL,  `nomempresa` varchar(75) COLLATE utf8_unicode_ci NOT NULL,  `direccion` varchar(30) COLLATE utf8_unicode_ci NOT NULL,  `telefono` int(20) NOT NULL,  `email` varchar(70) COLLATE utf8_unicode_ci NOT NULL,  `nomcontacto` varchar(50) COLLATE utf8_unicode_ci NOT NULL,  `telcontacto` int(20) NOT NULL,  PRIMARY KEY (`idempresa`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
 

[gnzsoloyo]

Bueno, ahora está más claro...
Empecemos por un detalle: A pesar de lo que estabas comentando antes, ninguno de los campos de la tabla es INT. No sé de dónde sacaste eso, pero a las pruebas me remito:

Código MySQL:

CREATE TABLE `empresas` (
    `idempresa` varchar(75) COLLATE utf8_unicode_ci NOT NULL,
    `nomempresa` varchar(75) COLLATE utf8_unicode_ci NOT NULL,
    `direccion` varchar(30) COLLATE utf8_unicode_ci NOT NULL,
    `telefono` varchar(10) COLLATE utf8_unicode_ci NOT NULL,
    `email` varchar(70) COLLATE utf8_unicode_ci NOT NULL,
    `nomcontacto` varchar(50) COLLATE utf8_unicode_ci NOT NULL,
    `telcontacto` varchar(10) COLLATE utf8_unicode_ci NOT NULL,
    PRIMARY KEY (`idempresa`)
)  ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE = utf8_unicode_ci
 

Son todos VARCHAR...
Y como los teléfonos están definidos como de 10 caracteres... pues simplemente no peudes ponerle más.
No sé si aconsejarte realmente que corrijas algunas cosas, porque veo que estás metiendo identificadores aparentemente numéricos (idempresa, por ejemplo) como VARCHAR, lo que implicaría que hay más de un error conceptual.
Tiene pinta de que al modelo le falta afinación.

Como sea, el primer problema es simple: Necesitas poner los teléfonos al menos como VARCHAR(14), y no 10. Y recordar que en los teléfonos no se almacenan signos, por lo que no pogas cosas como 56-3456-1234. Eso es incorrecto como diseño de datos.

Nota: ¿Por qué VARCHAR(14) y no más grande?
Pues porque la actual convención numérica de telefonía sólo soporta hasta 14 dígitos, incluyendo los de país y ciudad.
Por ejemplo: 5454749990001 (sería un número imaginario, pero de una localidad de la Provincia de Córdoba, Argentina, llamando desde el exterior).

Por ello, cualquier cosa que le pongas por encima de 14 caracteres resulta irrelevante... al menos por los próximos veinte años.

[Jlopez2014]

Como aclaré enseguida... las líneas de ese código era cuando cambie por un momento para probar los campos INT en VARCHAR (telefono y telcontacto), y lo del idempresa es Varchar porque la codificación de ella lleva tanto letras como números... no se si igual esto cambie las cosas... pues quiero saber porqué cuando estan en INT no soporta números de diez digitos pese a que su campo es de 20, que inicien con el 3... igual es más por curiosidad, pues quiero saber todos esos detalles... no tengo inconvenientes de cambiarlos a Varchar 14... gracias

[gnzsoloyo]

¿Leíste el link que te pasé?

Es bastante aclaratorio de tu duda, pero de todos modos vamos ahacer unaintroducción:

En las bases de datos, y en especial hablando de MySQL, los números no se almacenan como cifras, sino como números binarios. De este modo se puede usar sólo 8 bytes para representar un número que en realidad tiene 20 dígitos.
Pero si lees sobre representación o codificacion de números en binario, sabrás que en binario no existen los numeros negativos, pero como el mudo real si, se debió hacer una forma de convención que permita realizar operaciones con negativos, y que sea sportada en binario.
¿Cómo?
Bueno, se resolvió dedicar la mitad del rango de un numero binario a los positivos y otro a los negativos, más el cero (el cero tambien tiene que ser representado).
Ahora bien, las computadoras trabajan con longitudes de palabra que determinan por convención que la menor representacion codificada es un Byte, el cual se estableció en 8 bits.
El rango es: 00000000 a 11111111.
El 11111111 es el binario de 255, mientras que el otro es el cero.
Cuando quieres representar los negativos haces que todos los que comienzan con 1 en el primer bit sean negativos y el resto positivos:

(1) 1111111 = -128
(0) 0000000 = 0
(0) 1111111 = 127

De alli que haya más negativos que positivos en la representación de números con signo.
Entonces MySQL definió cinco tipos de números enteros:

TINYINT = 1 Byte (8 bits)
SMALLINT = 2 Bytes (16 bits)
MEDIUMINT = 3 Bites (24 bits)
INT = 4 Bytes (32 bits)
BIGINT = 8 Bytes (64 bits).

En consecuencia lo que define el rango de representación de un número en MySQL es el tipo de dato, no otra cosa.
Ahora bien, para entenderlo correctamente, veamos lo que dice el manual:

Con signo:

TINYINT: -128 a 127
SMALLINT: -32768 a 32767
MEDIUMINT: -8388608 a 8388607
INT: -2147483648 a 2147483647
BIGINT: -9223372036854775808 a 9223372036854775807

Sin signo:
TINYINT: 0 a 255
SMALLINT: 0 a 65535
MEDIUMINT: 0 a 16777215
INT: 0 a 4294967295
BIGINT: 0 a 18446744073709551615

Como verás, en cada caso hay un máximo de dígitos representables, pero también un valor máximo, pero lo que vale a la hora de los números es el tipo de dato.

Entonces, ¿qué significa ese numerito absurdo en la definición del dato?

En realidad nada útil. A mi entender MySQL debería eliminarlo porque sólo produce confusiones, pero yendo al manual el tema es así:

MySQL soporta otra extensión para especificar de forma óptima el ancho a mostrar de un tipo entero en paréntesis después de la palabra clave para el tipo (por ejemplo, INT(4)). Esta especificación opcional del ancho de muestra se usa para alinear a la izquierda la muestra de los valores con ancho menor que el ancho especificado para la columna.

El ancho de muestra no restringe el rango de valores que pueden almacenarse en la columna, sino el número de dígitos que se muestran para valores con ancho que exceda el especificado para la columna.

Cuando se usa en conjunción con el atributo de extensión opcional ZEROFILL, el relleno por defecto de espacios se replaza por ceros. Por ejmplo, para una columna declarada como INT(5) ZEROFILL, un valor de 4 se muestra como 00004. Tenga en cuenta que si almacena valores mayores que el ancho de muestra en una columna entera, puede tener problemas cuando MySQL genera tablas temporales para algunos joins complicados, ya que en estos casos MySQL cree que los datos encajan en el ancho original de la columna.

Todos los tipos enteros pueden tener un atributo opcional (no estándar) UNSIGNED. Los valores sin signo pueden usarse cuando quiere permitir sólo números no negativos en una columna y necesita un rango numérico mayor para la columna.

Ese "ancho a mostrar" sólo tiene efectos reales en las operaciones de SQL que se hacen sobre consola de MySQL, y no cuando aplicas SQL a través de una aplicación.
Por otra parte hay un efecto secundario y es que esa definición extra de la columna se usa luego cuando se utilizan VIEWs, donde MySQL se referencia a esa definición para realizar ciertas operaciones. Por esa razon no es conveniente jamás indicar un ancho menor al máximo representable del tipo de dato, ya que luego pueden generarse pérdida de datos, o recortes de representación con efectos impredecibles.
Si los quieres usar, dejale el valor por default. No lo manipules.

¿Se va entendiendo algo?