Cita:
|
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.
