I will open issues on dblook this weekend. I will update once I have more information. Thanks.
Brett ________________________________________ From: Rick Hillegas [rick.hille...@oracle.com] Sent: Thursday, August 11, 2011 11:04 AM To: derby-dev@db.apache.org Subject: Re: Error when running SYSCS_UTIL.SYSCS_CHECK_TABLE 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 [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)? >> > > > > >
