[
https://issues.apache.org/jira/browse/DERBY-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Cook updated DERBY-7043:
-----------------------------
Description:
DROP SCHEMA schemaname RESTRICT results in:
*{color:#d04437}ERROR XSAI2: The conglomerate (1,024) requested does not
exist.{color}*
Prior to DROP SCHEMA, I did drop all tables in that schema.
I realize that 1,024 conglomerate number translates into c400.dat file in Derby
seq0 directory, and that c400.dat file is indeed missing, and I neither know
why nor for how long.
I ran consistency checks on database using SQL commands from
[https://wiki.apache.org/db-derby/DatabaseConsistencyCheck] to find the bad
table(s):
*{color:#14892c}I isolated the 1,024 conglomerate error to the
SYS.SYSSEQUENCES table.{color}*
And I used the following SQL to identify the conglomerate name:
{color:#654982}*SYSSEQUENCES_HEAP*{color}
SELECT C.CONGLOMERATENUMBER, C.CONGLOMERATENAME, S.SCHEMANAME FROM
SYS.SYSCONGLOMERATES C, sys.sysschemas s WHERE CONGLOMERATENUMBER = 1024 AND
s.schemaid = C.schemaid
In fact, I cannot even SQL SELECT on SYS.SYSSEQUENCES table without getting the
same conglomerate error as the DROP SCHEMA schemaname RESTRICT command.
In other words, I cannot DROP SCHEMA schemaname RESTRICT until SYS.SYSSEQUENCES
corruption is resolved.
I was wondering if anyone knew how to resolve this easily with either SQL
command(s) or any UNIX style java commands that I can run from QSH environment
on our IBM Power9 (a.k.a. AS400).
P.S. Keep in mind, that I am not an IJ expert, as I have been using a simple
front-end Derby tool created by our manufacturer to run SQL statements on Derby
DB, without all the complexity of using IJ and setting up IJ with environment
variables, classpaths, etc.
was:
DROP SCHEMA schemaname RESTRICT results in:
*{color:#d04437}ERROR XSAI2: The conglomerate (1,024) requested does not
exist.{color}*
Prior to DROP SCHEMA, I did drop all tables in that schema.
I realize that 1,024 conglomerate number translates into c400.dat file in Derby
seq0 directory, and that c400.dat file is indeed missing, and I neither know
why nor for how long.
I ran consistency checks on database using SQL commands from
[https://wiki.apache.org/db-derby/DatabaseConsistencyCheck] to find the bad
table(s):
*{color:#14892c}I isolated the 1,024 conglomerate error to the
SYS.SYSSEQUENCES table.{color}*
And I used the following SQL to identify the conglomerate name:
{color:#654982}*SYSSEQUENCES_HEAP*{color}
SELECT C.CONGLOMERATENUMBER, C.CONGLOMERATENAME, S.SCHEMANAME FROM
SYS.SYSCONGLOMERATES C, sys.sysschemas s WHERE CONGLOMERATENUMBER = 1024 AND
s.schemaid = C.schemaid
In fact, I cannot even SQL SELECT on SYS.SYSSEQUENCES table without getting the
same conglomerate error as the DROP SCHEMA schemaname RESTRICT command.
In other words, I cannot DROP SCHEMA schemaname RESTRICT until SYS.SYSSEQUENCES
corruption is resolved.
I was wondering if anyone knew how to resolve this easily with SQL command(s)?
P.S. Keep in mind, that I am not an IJ expert, as I have been using a simple
front-end Derby tool created by our manufacturer to run SQL statements on Derby
DB, without all the complexity of using IJ and setting up IJ with environment
variables, classpaths, etc.
> DROP SCHEMA results in ERROR XSAI2
> ----------------------------------
>
> Key: DERBY-7043
> URL: https://issues.apache.org/jira/browse/DERBY-7043
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.8.2.2
> Environment: OS/400
> Reporter: Rick Cook
> Priority: Minor
>
> DROP SCHEMA schemaname RESTRICT results in:
> *{color:#d04437}ERROR XSAI2: The conglomerate (1,024) requested does not
> exist.{color}*
> Prior to DROP SCHEMA, I did drop all tables in that schema.
> I realize that 1,024 conglomerate number translates into c400.dat file in
> Derby seq0 directory, and that c400.dat file is indeed missing, and I neither
> know why nor for how long.
> I ran consistency checks on database using SQL commands from
> [https://wiki.apache.org/db-derby/DatabaseConsistencyCheck] to find the bad
> table(s):
> *{color:#14892c}I isolated the 1,024 conglomerate error to the
> SYS.SYSSEQUENCES table.{color}*
> And I used the following SQL to identify the conglomerate name:
> {color:#654982}*SYSSEQUENCES_HEAP*{color}
> SELECT C.CONGLOMERATENUMBER, C.CONGLOMERATENAME, S.SCHEMANAME FROM
> SYS.SYSCONGLOMERATES C, sys.sysschemas s WHERE CONGLOMERATENUMBER = 1024 AND
> s.schemaid = C.schemaid
> In fact, I cannot even SQL SELECT on SYS.SYSSEQUENCES table without getting
> the same conglomerate error as the DROP SCHEMA schemaname RESTRICT command.
> In other words, I cannot DROP SCHEMA schemaname RESTRICT until
> SYS.SYSSEQUENCES corruption is resolved.
> I was wondering if anyone knew how to resolve this easily with either SQL
> command(s) or any UNIX style java commands that I can run from QSH
> environment on our IBM Power9 (a.k.a. AS400).
> P.S. Keep in mind, that I am not an IJ expert, as I have been using a simple
> front-end Derby tool created by our manufacturer to run SQL statements on
> Derby DB, without all the complexity of using IJ and setting up IJ with
> environment variables, classpaths, etc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
