Hi Stanley,

Thanks for your message.

The problem is happening on the Page 0 [the first page] of conglomerate 1313 (the conglomerateId) - you can see what table/index this corresponds to with the following query:

select CONGLOMERATENUMBER, CONGLOMERATENAME
 from sys.sysconglomerates
 where conglomeratenumber =  1313;

From the errors in your log I suspect this to be the table or one of the indexes of the failing query listed:
   INSERT INTO text_table (guidhigh, guid, data)

That's correct - there are essentially two types of queries which seem to cause the issue on the text_table table. Either the insertion of blob data into text_table (it is compressed text), or a select call check for the existence of an entry given guidhigh and guid.

Does your database reboot without any errors after the shutdown/crash?

You wrote: " /Derby locates the error, reboots the database, but seems to inevitably report the same error again./ "

I assume this means you get the same exception when the database reboots (indicating the change was written to the transaction log and is replaying the error as the database attempts to recover when the db reboots).

That's right. I just tried explicitly restarting the application by killing off the process (there is a nanny process which detects this and automatically restarts it). However I still get the same derby errors on startup.

1) the databases are created in the directory D:\temp... If you suspect that this directory is every purged/cleared then this in not a good place to have database files. The files should be in a permanent and secure location.

In this case the d:\ is a raid array, and even though it is written to a directory called temp, nothing is being deleted from it. There are no virus scanners running either.

anything. Alternately if you shutdown the system then attempt to access the database from a newly started JVM ( I would use IJ) and still get the exception this shows that uncollected derby objects are not the problem.

Yes - I have confirmed that restarting the JVM still reports the same error on startup I am afraid.

Any ideas on what to check for now?

--
Cheers,
David

Nuix Pty Ltd
Suite 79, 89 Jones St, Ultimo NSW 2007, Australia    Ph: +61 2 9280 0699
Web: http://www.nuix.com                            Fax: +61 2 9212 6902

Reply via email to