db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <kristian.waa...@oracle.com>
Subject Re: Error XSDBB When Trying to Access DB From Windows, But Works In UNIX
Date Fri, 10 Dec 2010 15:53:01 GMT
  On 10.12.10 16:35, BEK1976 wrote:
> 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?


> 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

View raw message