[ 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
|