Error al definir una FOREIGN KEY

[Angel.Matilla]

Haré la prueba. No obstante el error me deja perplejo porque ambas columnas contienen el mismo tipo de datos.

[Angel.Matilla]

Estaba repasando el código que tengo hecho hasta ahora y me he dado cuenta de una cosa. Como comentaba lo que está pasando es que tengo que ampliar la base de datos de una aplicación ya existente; me he dado cuenta que en la carga inicial de datos, que proceden de una BB.DD. Paradox, las restricciones (CHECK y FOREIGN KEY) las defino después de haber cargado la tabla y no tuve ningún problema, y son unas cuantas.

[Casimiro Noteví]

¿Paradox es una BD relacional?

[Angel.Matilla]

No, ya sé que no. Digo que los datos originales estaban tablas Paradox. Me refería a las restricciones en FB.

[Casimiro Noteví]

Empezado por Angel.Matilla

No, ya sé que no. Digo que los datos originales estaban tablas Paradox. Me refería a las restricciones en FB.

Es que en este caso en concreto, habría que ver esos datos que tienes. Paradox "se los traga" porque no es relacional.

[orodriguezca]

¿Los scripts SQL para crear las tabla POBLACION y DATLOC fueron obtenidos de la base de datos?. El mensaje de error indica que hay alguna discrepancia en la definición de la columna CODPRV entre las dos tabla, posiblemente el Collation.

[Angel.Matilla]

Empezado por Casimiro Notevi

Es que en este caso en concreto, habría que ver esos datos que tienes. Paradox "se los traga" porque no es relacional.

A ver. En la BB.DD. Paradox hay columnas (en concreto CodPrv) que no están definidas, pero al hacer la carga de Paradox a FB ya lo tengo en cuenta y pongo un valro que sé no me va a dar error; en este caso concreto el valor que debe ir es 13 por la provincia de Ciudad Real y antes de ejecutar los INSERT correspondientes ya he cambiado el valor por defecto de 99 al que corresponde, 13 en este caso. Piensa que ambas bases de datos son "invento" mío.

Empezado por orodriguezca

¿Los scripts SQL para crear las tabla POBLACION y DATLOC fueron obtenidos de la base de datos?. El mensaje de error indica que hay alguna discrepancia en la definición de la columna CODPRV entre las dos tabla, posiblemente el Collation.

Los scripts son código del programa Builder. Como puedes ver en ambos esa columna CodPrv está definida igual (VARCHAR(2)), lo mismo que esa columna Poblacion (que haciendo caso a ecfisa he bautizado de otra manera para evitar confusiones) es un entero en ambas tablas. Tal vez, y sólo tal vez, habría que definirlas como VARCHAR(3) o VARCHAR(4) ya que el avlro de ese campo podría llegar a ser 100. Y, por cierto, ¿a qué collation te refieres?

[Angel.Matilla]

A mi una de las cosas que más me sorprende es que en la carga inicial de la BB.DD. a partri de las tabals Paradox he podido hacer la definición de las restricciones DESPUÉS de cargar las tablas y ahora que tengo que definir nuevas tablas no me deja hacer esa definición.

Una cosa que se me ocurre, y seguramente será una burrada: La tabla DATLOC, como otras nuevas que hay que definir, es evidente que está vacía; dado que esta tabla no tiene datos y la tabla POBLACION no está vacía, ¿podría ser que el problema viniera por ahí? ¿Tal vez sería interesante crear un fila "fantasma" en DATLOC para evitar ese problema?

[orodriguezca]

Empezado por Angel.Matilla

Y, por cierto, ¿a qué collation te refieres?

Me refiero a que cuando se crea una tabla se puede definir el collation_name de cada una de las columnas de tipo carácter. El siguiente es un fragmento de la sintaxis de la sentencia Create Table:

CREATE TABLE
Used for: creating a new table (relation)
Available in: DSQL, ESQL

Syntax:
CREATE [GLOBAL TEMPORARY] TABLE tablename
[EXTERNAL [FILE] '<filespec>']
(<col_def> [, {<col_def> | <tconstraint>} ...])
[ON COMMIT {DELETE | PRESERVE} ROWS];

<col_def> ::= <regular_col_def> | <computed_col_def>

<regular_col_def> ::=
colname {<datatype> | domainname}
[DEFAULT {literal | NULL | <context_var>}]
[NOT NULL]
[<col_constraint>]
[COLLATE collation_name]

Si se trata de establecer una integridad referencial entre dos tabla, entre columnas varchar, y si las columnas varchar tienen diferente collation_name saltará el error: Partner index segment no 1 has incompatible data type

En preguntas frecuentes de Firebird se encuentra lo siguiente:

"Partner index segment no 1 has incompatible data type

This usually means that the field in the foreign key you're trying to create has a different data type then the field of the primary key column it is referencing.

The difference can be subtle, anything that affects index (even field collation) is taken info account.

To solve this problem, usually the right thing to do is to change the data type of the foreign key columns before creating the foreign key constraint. "



Edito: De ser posible borrar (drop table, no delete) ambas tablas y vuelve a crearlas.