Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (nike.apache.org: domain of knut.hatlen@oracle.com
 designates 141.146.126.69 as permitted sender)
From: Knut Anders Hatlen <knut.hatlen@oracle.com>
To: derby-user@db.apache.org
Subject: Re: Database Table Null Pointer Exception
References: <1387233961800-136115.post@n7.nabble.com>
Mail-Copies-To: never
Mail-Followup-To: derby-user@db.apache.org
Date: Tue, 17 Dec 2013 13:01:15 +0100
In-Reply-To: <1387233961800-136115.post@n7.nabble.com> (irajon's message of
	"Mon, 16 Dec 2013 14:46:01 -0800 (PST)")
Message-ID: <wjo8eh5bptys.fsf@khepri41.no.oracle.com>
User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain

irajon <sil@gpmlife.com> writes:

> I use Derby as an embedded database.  My program Is sent to clients with the
> database.  I have a client that installed an update to my software and
> somehow, a new table was generated incorrectly.  The program did a create
> table, but when I look at this client's database, I don't see the new table. 
> When I try to create the table in the client's database, it says that the
> database already exists, and when I try to drop the table, it gives me a
> null pointer exception.  
> I ran the following sql query select * from SYS.SYSCONGLOMERATES left outer
> join sys.systables on SYS.SYSCONGLOMERATES.tableid = sys.systables.tableid. 
> this produced a listing of all of my tables and conglomerates etc... 
> There is an extra line in the result that has a conglomerate, but no table
> data.  I'm assuming, this is the corruption.  
> Please let me know if this is correct, and how I can fix the issue.  I have
> been working on trying to export the data, and then bring the data back to a
> new uncorrupted database, but there is a lot of work involved because of
> foreign keys and such.  

Hi irajon,

I think your analysis is correct, unfortunately, that your database has
been corrupted. As to fixing it, it sounds like you're on the right path
with exporting the good tables and importing them into a fresh database.

You might want to take a look at the ForeignTableVTI table function
described in https://issues.apache.org/jira/browse/DERBY-4962, which
helps migrating data between two databases. (Although it won't help with
working around the foreign key constraints.)

It's difficult to say whether the corruption happened because of a bug
in Derby or something else (for example, misconfigured file system or
disk error). If you know more details about what happened (such as: any
exceptions logged in derby.log around the time the corruption happened,
or if there was a crash or power failure), that information might be
useful to put in a bug report. But I'm afraid the root cause of such
problems tends to be difficult to track down without a reproducible test
case.

Hope this helps,

-- 
Knut Anders