Database Table Null Pointer Exception

[irajon <si...@gpmlife.com>]

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.  

Thanks



--
View this message in context: http://apache-database.10148.n7.nabble.com/Database-Table-Null-Pointer-Exception-tp136115.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.

Re: Database Table Null Pointer Exception

[Rick Hillegas <ri...@oracle.com>]

On 12/17/13 4:01 AM, Knut Anders Hatlen wrote:
> irajon<si...@gpmlife.com>  writes:
>
...
> 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.)
>
If you can upgrade to 10.10.1, the optional foreignViews tool may help 
you migrate your data: 
http://db.apache.org/derby/docs/10.10/tools/rtoolsoptforeignviews.html

Hope this is useful,
-Rick

Re: Database Table Null Pointer Exception

[Knut Anders Hatlen <kn...@oracle.com>]

irajon <si...@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