db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1641) Conglomerate requested does not exist after syscs_import_table with FK
Date Thu, 10 Aug 2006 18:45:15 GMT
     [ 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:
>         Environment: Java 1.5.0_06-b05 Linux (CentOS 4)
>            Reporter: Matt Frantz
>            Priority: Critical
>             Fix For:
> 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

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


View raw message