Cambiar DOMAIN de INTEGER a CHAR(6)

[RESP 3.0]

Realice el cambio y todo bien hasta que intente almacenar un valor alfanumerico en el campo en mencion, me da un error de conversion de string, es posible realizar ese cambio de dominio, lo hice asi:

Código SQL [-]
UPDATE RDB$FIELDS SET
RDB$FIELD_TYPE = 14,
RDB$FIELD_LENGTH = 6,
RDB$CHARACTER_LENGTH = 6
WHERE (RDB$FIELD_NAME = 'DM_MANO_OBRA');

Cabe mencionar que el campo es la llave primaria de la tabla y ademas es foranea en otras 2 tablas.

[marcoszorrilla]

Pues no es buena idea meterse con las tablas del sistema.

Yo crearía un nuevo campo Char(6) luego le pasaría todos los datos del antiguo campo convirtiéndolos como es lógico a Char.

Por último desactivaría las claves foraneas, quitaría también la clave primaria, eliminaría el antiguo campo, renombraría el nuevo y volvería a armar la clave única así como las claves foraneas, sin perder de vista que la clave primaria ahora es de tipo Char, lo cual puede llevar a que las claves foraneas si antes eran numéricas haya que reconvertirlas tambien.

Un Saludo.

[jachguate]

Empezado por RESP 3.0

Código SQL [-]
UPDATE RDB$FIELDS SET
RDB$FIELD_TYPE = 14,
RDB$FIELD_LENGTH = 6,
RDB$CHARACTER_LENGTH = 6
WHERE (RDB$FIELD_NAME = 'DM_MANO_OBRA');

Para comenzar, debo confesar que es algo sobre lo que hasta la fecha no he investigado, pero supongo que esto simpelemente provocará una serie de problemas con el sistema. Si lo pensas bien, te vas a dar cuenta que no estás cambiando para nada la representación física de los datos. Estos siguen como antes.

El motor usa el diccionario de datos para saber de que manera interpretar los datos físicos, que al final de cuentas son un puñado de bits. Si vos cambias la "mascara", pues estas por tu cuenta y riesgo. Es como hacer un cast en pascal, si sabes lo que haces, perfecto, pero si no, no lo hagas.

Trataré de explicarme con un ejemplo: si tenias un número 123, esto es diferente de la cadena '123' (de la primera clase de progra, no?).

Suponiendo una representación binaria, y suponiendo que firebird decidiera almacenar el número como un entero de 2 bytes, 123 se almacenaría como la siguiente secuencia de bits:

0000000001111011

en cambio '123' que ocupa 3 bytes sería algo como:

001100010011001000110011 (49,50,51 en decimal).

Si luego le decimos a firebird que interprete la primera cadena, vamos a obtener un resultado "inesperado", lo cual es predecible en este caso.

La única forma que habria de salvar esto, es que el motor implementara, quizas via triggers en las tablas del diccionario, el cambio de representación física cuando se hace un update sobre la tabla, pero fráncamente no creo que lo hagan.

Hasta luego.

[RESP 3.0]

Bueno gracias por contestar mucha, yo realice la modificacion de las tablas del sistema asumiento que la conversion la realizaba el Firebird en triggers de las tablas pero pude corroborar que no es asi, lo que voy a hacer es lo que dice Marcos, es una buena solucion.

Gracias por su atencion y por tomarse la molestia de contestarme.