Thanks, Brett. Some comments inline...
On 8/11/11 4:12 AM, Bergquist, Brett wrote:
Ran it again. It took quite a bit longer with the sane jars, almost 24 hours
this time. However, the same error is reported. Derby.log has no stack trace
either. I ran the check on all schemas and all tables except this one with no
problem. I will try this again just to double check that the sane jars are
absolutely used but maybe I will just write a quick app and call the procedure
without going through IJ.
Sounds like a good plan. In unraveling the exception, keep in mind the
possibility that the original error may be chained off of the top level
exception. The exception chaining can be a bit involved because you may
need to follow both SQLException.getNextException() and
Throwable.getCause().
Any other suggestions are welcome.
I am writing a utility to make a copy of the database by using dblook,
syscs_util.syscs_export_table and syscs_util.syscs_import_table procedures to
create a new database with the same schema and then export each table from one
database and import the table into the new database. I did find a couple of
problems with dblook:
1. dblook does not set an error code when exiting so there is no easy way to
see if it had a problem
2. dblook does not output a statement for the derby.database.classpath
property. If the database has jars in the database then this property is
probably set to access the procedures and functions within and as such should
be output by dblook.
These sound like defects to me. Would you mind filing JIRAs for these
problems? Problem (2) seems to be part of a larger defect: dblook
doesn't dump the values of properties stored in the database.
Thanks,
-Rick
________________________________________
From: Bergquist, Brett [[email protected]]
Sent: Tuesday, August 09, 2011 12:56 PM
To: [email protected]
Subject: RE: Error when running SYSCS_UTIL.SYSCS_CHECK_TABLE
I will try it with the sane jars tonight. I am able to export all of the data
in the table using the SYSCS_UTIL.SYSCS_EXPORT_TABLE procedure. I am also
running SYSCS_UTIL.SYSCS_CHECK_TABLE on all of the other tables right now to
see if it just this one.
-----Original Message-----
From: Rick Hillegas [mailto:[email protected]]
Sent: Tuesday, August 09, 2011 11:58 AM
To: [email protected]
Subject: Re: Error when running SYSCS_UTIL.SYSCS_CHECK_TABLE
Hi Brett,
Is there anything in derby.log? If you run with the debug/sane jars, I
would expect that derby.log would hold a complete stack trace with line
numbers.
Thanks,
-Rick
On 8/9/11 8:24 AM, Bergquist, Brett wrote:
Database engine is 10.8.1.2 (built from source with a patch for
Restricted table support) and I am running this in embedded mode. Am
getting the following error:
ERROR 38000: The exception 'java.lang.NullPointerException' was thrown
while evaluating an expression.
ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
Note that this database is suspect to have corruption. The table I am
trying to check has 74M rows in it and this runs for about 15 hours
before this gets reported. Derby.log looks like:
----------------------------------------------------------------
Thu Sep 01 12:21:29 EDT 2011:
Booting Derby version The Apache Software Foundation - Apache Derby -
10.8.1.2 - (678001): instance a816c00e-0132-25cb-8e35-00003ceac520
on database directory
/opt/canoga/canogaview/glassfish/databases/csemdb with class loader
sun.misc.Launcher$AppClassLoader@12360be0
Loaded from file:/opt/canoga/canogaview/glassfish/javadb/lib/derby.jar
java.vendor=Sun Microsystems Inc.
java.runtime.version=1.6.0_21-b06
user.dir=/opt/canoga/canogaview/glassfish/javadb
derby.system.home=null
Database Class Loader started - derby.database.classpath='CSEM.csemderby'
----------------------------------------------------------------
Thu Sep 01 14:27:50 EDT 2011: Shutting down Derby engine
----------------------------------------------------------------
Thu Sep 01 14:27:50 EDT 2011:
Shutting down instance a816c00e-0132-25cb-8e35-00003ceac520 on
database directory /opt/canoga/canogaview/glassfish/databases/csemdb
with class loader sun.misc.Launcher$AppClassLoader@12360be0
Is there anything I can turn on that would get better diagnostics of
where the problem is (where the NPE is being reported)?
