![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
||||
|
||||
|
No, Antonio, he pegado todas FK porque es muy útil extraerlas de una vez con el código de ECFISA, por si alguien le sirve más le pudiera servir.
En realidad lo que quiero hacer es cambiar el campo CODIGO de la tabla PVP que tiene ancho 10 a 12 (Varchar), pero no me deja porque es PK, no por Fk como pensaba. Un Saludo.
__________________
Guía de Estilo de los Foros Cita:
|
|
#2
|
||||
|
||||
|
Bueno, claro, es primary key, pero desde las las otras tablas relacionadas son foreign key a esa primary key
![]() Si tienes alguna tabla relacionada con ese campo entonces deberías desactivar en las relacionadas, modificar la primary* y luego volver a relacionar en las foreing. * Y si no puedes modificarla, entonces crea una tabla nueva con la longitud que quieras y copias los datos de la tabla original a la nueva. pd: por cierto, una primary key "es mejor" que sea integer, no varchar.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
#3
|
||||
|
||||
|
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:
![]() 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.
__________________
Tras casi seis años de trabajar para una empresa alemana como desarrollador Delphi, se vieron forzados a dejarme ir (temas presupuestales). Así que ahora estoy abierto a escuchar nuevas ofertas. |
|
#4
|
||||
|
||||
|
No hay ninguna clave externa apuntando a la tabla PVP el único impedimento es que el campo a modificar es clave primaria y no me deja ni eliminar la clave, ni siquiera el propio campo, pero si me deja eliminar la tabla entera.
Lo que pienso hacer mañana: 1. Crear una tabla igual pero con otro nombre PVP1, esto lo haré con el IbExpert la opción DDL, copio y pego el código en Tools - Script Executive. aqui ya cambio el ancho del campo modificando el DDL antes de ejecutar. 2.-Creada la nueva tabla vacía, ejecuto un SQL: Insert Into PVP1 Select * from PVP; 3.-Elimino PVP y renombro PVP1. Ya veremos lo que resulta. Un Saludo.
__________________
Guía de Estilo de los Foros Cita:
|
|
#5
|
||||
|
||||
|
Cita:
No sé si te sirva para el caso, pero suponiendo que ID es el nombre del campo y TABLA_PK el nombre de la restricción (PRIMARY KEY), para quitarla:
Para aplicarla nuevamente:
Saludos.
__________________
Daniel Didriksen Guía de estilo - Uso de las etiquetas - La otra guía de estilo .... |
|
#6
|
||||
|
||||
|
Voy a realizar esa prueba, porque el IbExpert no me deja quitar la clave, veré si me deja por SQL.
Un Saludo.
__________________
Guía de Estilo de los Foros Cita:
|
|
#7
|
||||
|
||||
|
Bueno gracias a todos y especialmente ECFISA, el SQL de su último mensaje ha funcioado.
Antecedentes:Cambiar el ancho del campo CODIGO Varchar(10) PK a 12. Desde el IbExpert no deja cambiar el ancho, ni eliminar el campo porque es Clave primaria, tampoco deja desactivar la clave primaria. Desde el ISQL ejecutando el SQL se soluciona todo. Un Saludo.
__________________
Guía de Estilo de los Foros Cita:
|
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Problemas con llaves foraneas | jcrg666 | MySQL | 1 | 01-04-2010 01:41:36 |
| Claves foraneas | Jcarloscgl | Firebird e Interbase | 2 | 26-02-2008 22:38:57 |
| Error con claves foráneas | david.rguez | MySQL | 1 | 08-02-2007 14:51:42 |
| LLaves foraneas... | Luis Castillo | SQL | 2 | 13-11-2005 19:45:34 |
| Llaves Foraneas | RainFall | MySQL | 1 | 26-07-2004 05:19:28 |
|