unir tablas

[manoloOZ]

hola, tengo un problema, quise cambiar el campo (codigo_postal) de varchar a tinyint y todos los valore q no eran nulos se transformaron en "127". hay alguna forma de revertirlo? sino hay, yo tengo esa misma tabla pero en una version un poco mas vieja en otra base me gustaria saber comohacer para que copie solo ese campo de la tabla vieja a la nueva para por lo menos no haber perdido tanta informacion.

muchas gracias

[gnzsoloyo]

Ese problema se te produjo porque no has verificado correctamente cual es el valor más alto que había en la tabla, antes de definir cuál es el tipo numérico conveniente.
Evidentemente, todos los valores no nulos superaban el 127, entonces, como el rango de representación de un TINYINT con signo es de -128 a 127, debiste haber usado un MEDIUMINT y no un TINYINT.
En todo caso, si ningún valor superaba el 255, y no tenías valores negativos ni los esperas tener, podrías haber usado un TINYINT UNSIGNED, cuyo rango es 0 a 255.
Ahora bien, como al cambiar el tipo de columna, el valor supera el rango, MySQL le asigna automáticamente el máximo posible para esa columna, el cual es 127.

¿Se entiende el problema?

No hay posibilidad de vuelta atrás en la conversión. Si conservas una copia de la tabla, deberás usarla para recuperar los datos. En caso contrario, deberás reingresarlos.

Por estas y otras razones es que una base de datos no debe modificarse cuando ya está en trabajo; y también por estas razones es que hay que planear bien cuál es el rango de datos necesario y suficiente para definir desde el principio el tipo de columnas correcto, siempre pensando a futuro.
Un cambio estructural en una base trabajando suele producir problemas grandes casi siempre (yo ya he tenido esas experiencias).

[manoloOZ]

Iniciado por gnzsoloyo

Ese problema se te produjo porque no has verificado correctamente cual es el valor más alto que había en la tabla, antes de definir cuál es el tipo numérico conveniente.
Evidentemente, todos los valores no nulos superaban el 127, entonces, como el rango de representación de un TINYINT con signo es de -128 a 127, debiste haber usado un MEDIUMINT y no un TINYINT.
En todo caso, si ningún valor superaba el 255, y no tenías valores negativos ni los esperas tener, podrías haber usado un TINYINT UNSIGNED, cuyo rango es 0 a 255.
Ahora bien, como al cambiar el tipo de columna, el valor supera el rango, MySQL le asigna automáticamente el máximo posible para esa columna, el cual es 127.

¿Se entiende el problema?

No hay posibilidad de vuelta atrás en la conversión. Si conservas una copia de la tabla, deberás usarla para recuperar los datos. En caso contrario, deberás reingresarlos.

Por estas y otras razones es que una base de datos no debe modificarse cuando ya está en trabajo; y también por estas razones es que hay que planear bien cuál es el rango de datos necesario y suficiente para definir desde el principio el tipo de columnas correcto, siempre pensando a futuro.
Un cambio estructural en una base trabajando suele producir problemas grandes casi siempre (yo ya he tenido esas experiencias).

sisi lo entendi y es lo q suponia... tengo una copia de la tabla pero uan version un poco mas vieja en otra base de datos, me gustaria saber como hacer para recuperar ese campo solo, copiandolo de la base copia a la original.

muchas gracias

[gnzsoloyo]

Una forma simple es hacer volcar la tabla vieja a una tabla temporal con la misma estructura, dentro de la base donde está la que estabas trabajando.

Código sql:

CREATE TABLE temporal AS 
SELECT * 
FROM tablaorigen;
 

Y luego hacer un UPDATE aprovechando que las PK de ambos registros deben coincidir:

Código sql:

UPDATE tabla T1 INNER JOIN tablaorigen T2 ON T1.pk1 = T2.pk2
SET T1.campo = T2.campo.
 

Atención:
Cuando pongo: T1.pk1 = T2.pk2 me estoy refiriendo a la clave primaria de la tabla en que estás trabajando, cruzandola con los mismos campos de la tabla recuperada.Como no conozco la estructura de la tabla estoy poniendo campos imaginarios. Tu pon los que correponden...