db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Cook (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-7043) DROP SCHEMA results in ERROR XSAI2
Date Thu, 02 May 2019 22:59:00 GMT

     [ 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}{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.

  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}*

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}{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.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message