You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Myrna van Lunteren (JIRA)" <ji...@apache.org> on 2014/06/09 18:59:02 UTC
[jira] [Resolved] (DERBY-6587) Foreign Key constraint not matched
when using UUID in a composite foreign key when using
SYSCS_UTIL.SYSCS_IMPORT_TABLE
[ https://issues.apache.org/jira/browse/DERBY-6587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Myrna van Lunteren resolved DERBY-6587.
---------------------------------------
Resolution: Fixed
Fix Version/s: 10.11.0.0
Bug behavior facts: (was: Deviation from standard)
The nightly test runs at IBM and Oracle look clean.
Fixed in 10.11, it will be in the upcoming release.
Thanks for your contribution, Pascal!
> Foreign Key constraint not matched when using UUID in a composite foreign key when using SYSCS_UTIL.SYSCS_IMPORT_TABLE
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-6587
> URL: https://issues.apache.org/jira/browse/DERBY-6587
> Project: Derby
> Issue Type: Bug
> Components: SQL, Tools
> Affects Versions: 10.10.2.0
> Environment: Windows 7, Java 7
> Reporter: Pascal GrĂ¼n
> Assignee: Myrna van Lunteren
> Fix For: 10.11.0.0
>
> Attachments: DERBY-6587_tst.diff, DERBY-6587_tst.diff2, RIBulkChecker.diff, TABLE1_T.csv, TABLE2_T.csv, schema.sql
>
>
> There is a problem in org.apache.derby.impl.sql.execute.RIBulkChecker:
> result = fkCol.compare(refCol);
> if (result == 1)
> {
> return GREATER_THAN;
> }
> else if (result == -1)
> {
> return LESS_THAN;
> }
> where the JavaDoc for "compare" explicitly states that one must not use 1 or -1 to check the return value.
> The problem can be reproduced when creating a table with two fields, "UUID_FIELD char (16) for bit data" and "NUM_FIELD integer", then having a foreign key to these two fields and then using the bulk import, i.e. "CALL SYSCS_UTIL.SYSCS_IMPORT_TABLE ..."
--
This message was sent by Atlassian JIRA
(v6.2#6252)