Hola Marcos.
Se trata de un problema de dependencias. No puedes cambiar el campo que hace de llave primaria en una tabla (ni su tipo, ni su longitud, ni nada), sin antes desactivar las llaves externas, es decir,
foráneas, que hay en otras tablas y que están relacionadas con esa primera tabla (llaves externas relacionadas con ese campo de llave primaria).
El diagrama de dependencias debería ser suficiente para averiguar qué tablas están "enganchadas" a la llave de la primera tabla. Es cosa de ubicarlas y eliminar su llave foránea de manera temporal. Haciendo lo anterior, podrás entonces eliminar la llave primaria con el fin de que ese campo quede "libre" para ser modificado.
Esto que dice Antonio es muy cierto:
Cita:
Empezado por Casimiro Notevi
pd: por cierto, una primary key "es mejor" que sea integer, no varchar.
|
Soy un convencido de lo anterior. Doy a cada tabla una
llave artificial, es decir, en todas ellas tengo un primer campo de tipo Integer llamado
ID, el cual hago llave primaria y sirve también de enlace con llaves externas de otras tablas.
Venta.IDCliente "apunta" a Cliente.ID
Los campos "Codigo", "Clave", "Numero" son la "llave" para el usuario del sistema. Pero internamente, la verdadera llave primaria, es siempre el campo ID, el cual nunca es mostrado en pantalla o impreso en un reporte, puesto que su función es interna: ser la
manija de cada registro.
Espero quede solucionado pronto.
Saludos.
Al.