[ http://issues.apache.org/jira/browse/DERBY-1641?page=all ]
Mike Matrigali updated DERBY-1641:
----------------------------------
Component/s: SQL
Adding SQL as component. Without debugging it is only a guess, but in my
experience this kind of problem is
almost always a SQL component problem either in datadictionary or some sort of
caching problem.
The interesting point is that the import table command is likely using the
"bait/switch" bulk load optimization which means that it is avoiding logging
everything being imported by creating entirely new tables and indexes as it
"knows" that the existing table is empty and then at the end it switches the
datadictionary to point Z at the new underlying store tables. The bug has the
feel that one of the datadictionary references for foreign key was not updated
(or if that was not meant to be supported then maybe bait/switch should not
have been allowed in this case).
> Conglomerate requested does not exist after syscs_import_table with FK
> ----------------------------------------------------------------------
>
> Key: DERBY-1641
> URL: http://issues.apache.org/jira/browse/DERBY-1641
> Project: Derby
> Issue Type: Bug
> Components: SQL, Store
> Affects Versions: 10.1.3.1
> Environment: Java 1.5.0_06-b05 Linux (CentOS 4)
> Reporter: Matt Frantz
> Priority: Critical
> Fix For: 10.2.0.0
>
>
> I have a repeatable sequence that always causes the "Conglomerate (X)
> requested does not exist" error on my system. There are several steps. You
> can use "ij" as follows:
> 1. Start with a new database, e.g. connect 'jdbc:derby:test;create=true';
> 2. create table y( pk integer primary key );
> 3. insert into y values (123);
> 4. create table z( pk integer not null primary key references y );
> 5. Create a file containing a single row of ASCII data with the number "123"
> (in ASCII) in it. e.g. /tmp/z
> 6. call syscs_util.syscs_import_table( null, 'Z', '/tmp/z', ',', '''', null,
> 1 );
> 7. Try to access the "Z" table, e.g. SELECT * FROM z; or DROP TABLE z;
> At this point, I always get the error. I can use this sequence in other
> contexts, but the difference, as far as I can tell, is that the table "Z" has
> a column that is both PK and FK.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
