irajon <[email protected]> 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
