Mailing-List: contact poi-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "POI Users List" <poi-user@jakarta.apache.org>
From: "Kais Dukes" <kd@kaisdukes.com>
To: "POI Users List" <poi-user@jakarta.apache.org>,
	<bbelvin@iss-md.com>
Subject: RE: Problem generating a large file when following the POIFS standard
Date: Wed, 25 Feb 2004 22:37:26 -0000
Message-ID: <JLELLGCOBPCGDLCPKAJLEELBCDAA.kd@kaisdukes.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <002401c3fbeb$47703c50$4b1ea8c0@HPBrandon>

Hi Brandon

If you are writing in C++, this isn't really a POI issue, but I've done some
work in this area. Make sure that you are generated XBATs in the following
way:

The BAT array is used to represent storage of the BAT.

The BAT array is also represented by an array of blocks, and is chained by
the terminating entry in each XBAT block. Hence, each XBAT blocks stores not
128, but 127 entries.

As an optimization, the first 109 BAT array entries are stored within the
header itself, so no XBAT blocks will be found in a small (< 6.8 MB)
structured storage document.

The storage for XBAT blocks are reserved in the BAT, but is not chained
there (space for it is reserved by a special value, -4). The location of the
first XBAT block is stored in the header. A value of ENDOFCHAIN (= -1) is
stored in the pointer to the next XBAT block of the last XBAT block (I don't
think this was mentioned in the POIFS document, I found it out myself my
examining hex dumps of Microsoft files).

Note that I've written an XBAT implementation which doesn't even modify the
BAT to allocate storage for it, and it works just fine with Microsoft's
native OLE2 reader.

-- Kais

-----Original Message-----
From: Brandon Belvin [mailto:bbelvin@iss-md.com]
Sent: 25 February 2004 22:04
To: POI User Mailing List
Subject: Problem generating a large file when following the POIFS
standard


As an add-on to an existing database front-end application, we have allowed
the user to export their report's data to Excel.  Following POIFS'
standards, we used C++ to write the Excel file.  Upon testing, we discovered
our code works perfectly for files under 6.8 MB.  For files larger than 6.8
MB, it is necessary to use an XBAT.  Excel will no longer open the file.
The error message states the file is not repairable and cannot extract data
from the file.

We adapted the code to calculate the number of XBATs needed and made
appropriate changes to the self-description in the BATs.  I've even gone so
far as to compare our generated file in HEX to an Excel XP file.  Everything
looks the same for same-size files with the exception that we do not
compress our string table.

At this point, OpenOffice will successfully open the file but Excel will
not.  If we save the OpenOffice file as an Excel file, it does open
properly.  Since we cannot ask our customers to do this, this is not an
viable solution.

What potential pitfalls might we have fallen into?  I'm thinking the problem
is related to our implementation of the XBAT, but I'm not sure since it
looks the same as an Excel XP file.  I'd be more than willing to provide a
generated file to anyone who is able to help.  Thanks in advance.

Brandon Belvin
Information Systems Support, Inc.


---------------------------------------------------------------------
To unsubscribe, e-mail: poi-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: poi-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: poi-user-help@jakarta.apache.org