[
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}*
{color:#14892c}And I used the following SQL to identify the conglomerate name:
{color}{color:#654982}*SYSSEQUENCES_HEAP*{color}
{color:#14892c}SELECT C.CONGLOMERATENUMBER, C.CONGLOMERATENAME, S.SCHEMANAME
FROM SYS.SYSCONGLOMERATES C, sys.sysschemas s WHERE CONGLOMERATENUMBER = 1024
AND s.schemaid = C.schemaid{color}
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, without all the complexity of IJ and without having to set up
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}*
{color:#14892c}{color:#333333}And I used the following SQL to identify the
conglomerate name:
{color}{color:#654982}*SYSSEQUENCES_HEAP*{color}{color}*{color:#14892c}
{color}*
{color:#14892c}{color:#333333}SELECT C.CONGLOMERATENUMBER, C.CONGLOMERATENAME,
S.SCHEMANAME FROM SYS.SYSCONGLOMERATES C, sys.sysschemas s WHERE
CONGLOMERATENUMBER = 1024 AND s.schemaid = C.schemaid{color}{color}
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, without all the complexity of IJ and without having to set up
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}*
> {color:#14892c}And I used the following SQL to identify the conglomerate
> name: {color}{color:#654982}*SYSSEQUENCES_HEAP*{color}
> {color:#14892c}SELECT C.CONGLOMERATENUMBER, C.CONGLOMERATENAME, S.SCHEMANAME
> FROM SYS.SYSCONGLOMERATES C, sys.sysschemas s WHERE CONGLOMERATENUMBER =
> 1024 AND s.schemaid = C.schemaid{color}
> 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, without all the complexity of IJ and without having to set up
> environment variables, classpaths, etc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
