On 10.12.10 16:35, BEK1976 wrote:
Hi,


Hi,

What I'm asking may very well be a red herring, but it would be nice to get it confirmed anyway. What's the underlying file system on the Windows machine, and what's the maximum allowed file size for that file system?


Regards,
--
Kristian

I'm trying to debug a strange error that just started occurring recently.
This past weekend, our Derby database began reporting error XSLA7 (Cannot
redo operation null in the log) and XSDBB (Unknown Page Format) when we try
to access data from the DB using a MATLAB GUI front-end tool that calls into
our internally-developed DB table utilities.  When we run our actual
application, which runs on IBM AIX using the same database table utilities,
the database works fine.

Note that these MATLAB developed tools have been working fine for quite some
time, and the errors seem to correlate to database size.  When we add enough
data to this one particular table to push one of the internal derby files
over 2 GB, that's when the error starts occurring.  It's also worth noting
is that we are running AIX on 64-bit machines, and we are running Windows on
32 bit machines.  Is there a known compatibility issue with Derby with
respect to populating a database in a 64 bit environment and then accessing
it in a 32 bit environment?

As another test, I tried connecting to the database via a portion of our
application code in Eclipse, bypassing the MATLAB tools.  We again get the
error when trying to query the database.

This problem first began occurring under Derby 10.5.1.  However, after
seeing this Derby error report
(https://issues.apache.org/jira/browse/DERBY-4239), which exactly matched
our errors, I upgraded to Derby 10.5.3 and reverted back to a version of the
database that did not exhibit the problem.  Unfortunately, that did not seem
to help -- once the DB got larger once again, we got the mostly the same
errors.  (I no longer get XSLA7, but still get XSDBB with the all-zeros hex
dump.)

Any help would be most appreciated!
Thanks,
-Brian

Reply via email to