Error al definir un FK en Firebird 2.5

[Angel.Matilla]

Estoy definiendo una clave externa sobre una tabla FB de la siguiente forma:

ALTER TABLE Persona 
ADD CONSTRAINT FK_CodAfiPer 
FOREIGN KEY (CodPrv, Afiliacion)
REFERENCES Afiliacion(CodPrv, Codigo)
ON DELETE SET DEFAULT ON UPDATE CASCADE

Las definiciones de los tablas son estas:

1. Personas:

Código SQL [-]
CREATE TABLE Persona (
  CodPrv VARCHAR(2) NOT NULL, 
  Codigo INTEGER NOT NULL, 
  Apellidos VARCHAR(40) NOT NULL, 
  Nombre VARCHAR(15) NOT NULL,
  Nif VARCHAR(9), 
  Sexo INTEGER, 
  F_nacim DATE, 
  Domicilio VARCHAR(50), 
  Cpostal VARCHAR(5), 
  Poblacion INTEGER, 
  Provincia INTEGER, 
  Profesion INTEGER, 
  C_electronico VARCHAR(60), 
  Telefono_1 VARCHAR(9), 
  Telefono_2 VARCHAR(9), 
  Telefono_3 VARCHAR(9), 
  Situacion INTEGER, 
  Correo INTEGER, 
  Lo1599 INTEGER, 
  F_alta DATE, 
  N_afiliado INTEGER, 
  Afiliacion INTEGER, 
  Junta INTEGER,
  Referencia VARCHAR(12), 
  Perpago INTEGER, 
  Forpago INTEGER, 
  Cuota DECIMAL(9, 2), 
  Iban VARCHAR(4), 
  Cuenta VARCHAR(30), 
  Bic VARCHAR(11), 
  Observaciones BLOB SUB_TYPE 1, 
  Errores BLOB SUB_TYPE 1, 
  UsuMod VARCHAR(15), 
  FecMod TIMESTAMP, 
  CONSTRAINT PK_Persona PRIMARY KEY (CodPrv, Codigo)
)

2. Afiliaciones:

Código SQL [-]
CREATE TABLE Afiliacion (
  CodPrv VARCHAR(2) NOT NULL, 
  Codigo INTEGER NOT NULL, 
  Nombre VARCHAR(30) NOT NULL, 
  Ant_Codigo INTEGER, 
  CONSTRAINT PK_Afiliacion PRIMARY KEY (CodPrv, Codigo)
)

Y al ejecutar el ALTER TABLE me da este error:

Unsuccessful metadata update.
Partner index segment no 1 has incompatible data type.

Que no sé por donde coger porque con ese mensaje entiendo que lso tipos de datos del primer campo del índice son diferente sy en ambos casos son VARCHAR(2).

[ecfisa]

Empezado por Angel.Matilla

Estoy definiendo una clave externa sobre una tabla FB de la siguiente forma:

ALTER TABLE Persona 
ADD CONSTRAINT FK_CodAfiPer 
FOREIGN KEY (CodPrv, Afiliacion)
REFERENCES Afiliacion(CodPrv, Codigo)
ON DELETE SET DEFAULT ON UPDATE CASCADE

Las definiciones de los tablas son estas:
...
Y al ejecutar el ALTER TABLE me da este error:
Que no sé por donde coger porque con ese mensaje entiendo que lso tipos de datos del primer campo del índice son diferente sy en ambos casos son VARCHAR(2).

Hola.

Aparentemente tenes una confusión entre un nombre de columna y un nombre de tabla, intenta así:

Código SQL [-]
ALTER TABLE PERSONA
ADD CONSTRAINT FK_CODAFIPER
FOREIGN KEY (CODPRV, CODIGO)
REFERENCES AFILIACION(CODPRV, CODIGO)
ON DELETE SET DEFAULT ON UPDATE CASCADE

Saludos

[Angel.Matilla]

Gracias por la respuesta ecfisa.

Ya sé que es un poco confuso pero la definición que puse yo es correcta. Al diseñar las tablas no me di cuenta y puse a una columna el mismo nombre que a una tabla. El campo que hay que ligar es Afiliación de la tabla Personas con el campo código de la tabla Afiliacion. Probablemente lo que haré será renombrar los campos para no liarme.

Estoy haciendo las pruebas de instalación definitivas y lo curioso es que esta misma definición de base de datos situada en otra carpeta funciona a la perfección todas las restricciones, y hay unas cuantas.

[Angel.Matilla]

Empiezo a pensaqr que el problema no está las definiciones y sí en la máquina. La respuesta anterior la he puesto mientras arrancaba el PC y la primera prueba que he hecho, desde SQL Manager no desde la aplicación, se ha ejecutado a la perfección sin dar ningún error.

He borrado la base de datos y al tratar de ejecutar desde la aplicación ha dado un error pero en otra línea diferente. Por si acaso he vuelto a borrar la base de datos y ejecutado desde SQL Manager el script que genera al definir las tablas y esta vez me ha dado error al crear la clave primaria, que luego se ha ejecutado bien. Tendré que darle una vuelta al disco duro.

[Casimiro Notevi]

¿Esa base de datos tiene datos?
Mejor dicho, ¿esas tablas tienen datos?

[[fjcg02]]

Si los campos en la definición están bien, y las tablas tienen datos, es que hay datos que incumplen la regla.


Saludos

[Casimiro Notevi]

Empezado por fjcg02

Si los campos en la definición están bien, y las tablas tienen datos, es que hay datos que incumplen la regla.
Saludos

[Angel.Matilla]

Empezado por fjcg02

Si los campos en la definición están bien, y las tablas tienen datos, es que hay datos que incumplen la regla.

Completamente de acuerdo con este comentario salvo por una cosa: estoy creando la base de datos y por lo tanto las tablas están vacías. No sé que habré hecho; exactamente este mismo código me ha funcionado a la perfección y es ahora cuando estoy haciendo pruebas definitivas para instalar la aplicación al cliente que me da estos errores.

[[fjcg02]]

Mira a ver si te cruje porque el segundo campo es integer not null en un caso y en otro sólo integer.

No sé, creo que el mesaje no es tan claro como debiera y crea confusión.

Saludos

Edito: si utilizas set default en el caso de borrado, firebird te pondrá esos campos a nulos. Tu campo de la tabla Afiliacioens no puede ser null, por lo que te cruje.
Soluciones:
- hacer tu campo CodPrv de la tabla afiliaciones "nullable" ( como me vea Al me mata, jejejej)
- Quitar lo marcado y sustituir al gusto

ALTER TABLE PERSONA
ADD CONSTRAINT FK_CODAFIPER
FOREIGN KEY (CODPRV, CODIGO)
REFERENCES AFILIACION(CODPRV, CODIGO)
ON DELETE SET DEFAULT ON UPDATE CASCADE

[Angel.Matilla]

Empezado por fjcg02

Mira a ver si te cruje porque el segundo campo es integer not null en un caso y en otro sólo integer.

No sé, creo que el mesaje no es tan claro como debiera y crea confusión.

Saludos

Edito: si utilizas set default en el caso de borrado, firebird te pondrá esos campos a nulos. Tu campo de la tabla Afiliacioens no puede ser null, por lo que te cruje.
Soluciones:
- hacer tu campo CodPrv de la tabla afiliaciones "nullable" ( como me vea Al me mata, jejejej)
- Quitar lo marcado y sustituir al gusto

¡Vaya! No se me había ocurrido esta posibilidad. Probaré y gracias.

[[fjcg02]]

Empezado por Angel.Matilla

¡Vaya! No se me había ocurrido esta posibilidad. Probaré y gracias.

No es que se te ocurra o no. La propia definición de las fks indica que si pones "on delete set default", cuando borres un registro, los registros de la tabla referenciada afectados se actualizarán con valor nulo en los valores llave. Si el campo llave no puede ser nulo, te da una excepción al crear la fk impidiéndote crearla.


De lo cual deduzco que tu entorno de pruebas no es igual que el entorno que estás creando en tu cliente, bien en la definición de las tablas, bien en la definición de la fk.

Manténnos informados...

Saludos