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.
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. ________________________________________ From: Bergquist, Brett [bbergqu...@canoga.com] Sent: Tuesday, August 09, 2011 12:56 PM To: derby-dev@db.apache.org 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:rick.hille...@oracle.com] Sent: Tuesday, August 09, 2011 11:58 AM To: derby-dev@db.apache.org 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)? >
