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 "Matt Frantz (JIRA)" <de...@db.apache.org> on 2006/08/04 02:07:15 UTC
[jira] Created: (DERBY-1641) Conglomerate requested does not exist
after syscs_import_table with FK
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
Affects Versions: 10.1.3.1
Environment: Java 1.5.0_06-b05 Linux (CentOS 4)
Reporter: Matt Frantz
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
[jira] Updated: (DERBY-1641) Conglomerate requested does not exist
after syscs_import_table with FK
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1641?page=all ]
Kathey Marsden updated DERBY-1641:
----------------------------------
Fix Version/s: 10.2.0.0
Priority: Critical (was: Major)
I verified this on 10.2 and verified that I still get the conglomerate does not exist error after exiting ij and reconnecting to the database. Bumping to critical and marking as 10.2 candidate.
$ java org.apache.derby.tools.ij
ij version 10.2
ij> connect 'jdbc:derby:wombat;create=true';
ij> create table y(pk integer primary key);
0 rows inserted/updated/deleted
ij> insert into y values(123);
1 row inserted/updated/deleted
ij> create table z( pk integer not null primary key references y );
0 rows inserted/updated/deleted
ij> call syscs_util.syscs_import_table( null, 'Z', '/temp/z', ',', '''', null,1);
0 rows inserted/updated/deleted
ij> select * from z;
ERROR XSAI2: The conglomerate (1,009) requested does not exist.
> 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
> 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
[jira] Updated: (DERBY-1641) Conglomerate requested does not exist
after syscs_import_table with FK
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1641?page=all ]
Kathey Marsden updated DERBY-1641:
----------------------------------
Component/s: Store
put this as component store. Not sure if that is right.
> 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: 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
[jira] Updated: (DERBY-1641) Conglomerate requested does not exist
after syscs_import_table with FK
Posted by "Mike Matrigali (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Resolved: (DERBY-1641) Conglomerate requested does not exist
after syscs_import_table with FK
Posted by "Suresh Thalamati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1641?page=all ]
Suresh Thalamati resolved DERBY-1641.
-------------------------------------
Fix Version/s: 10.3.0.0
Resolution: Fixed
This is a duplicate of DERBY-1854 . Fixed in 10.2 , revision 449013 and in 10.3. revision 448758.
> 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.2.0, 10.3.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
[jira] Updated: (DERBY-1641) Conglomerate requested does not exist
after syscs_import_table with FK
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1641?page=all ]
Rick Hillegas updated DERBY-1641:
---------------------------------
Fix Version/s: 10.2.2.0
(was: 10.2.1.0)
Moving to 10.2.2.0
> 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.2.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