[ic] More problems with Spreadsheet Export

[Mike Heins]

Quoting cfm@maine.com (cfm@maine.com):
> On Fri, Dec 21, 2001 at 09:52:17AM -0600, Jason Kohles wrote:
> > On Fri, Dec 21, 2001 at 11:09:54AM -0000, Jonathan Clark wrote:
> > > Mike Heins wrote:
> > > >
> > > > This is true of Excel '95, but not of '97 and above. I have actually
> > > > tested spreadsheet import and export of text fields greater than
> > > > 256 characters on Excel 2000 and '97.
> > > >
> > > 
> > > Is this a case of the dbm type database field limitation of 256 chars then?
> > > 
> > The only dbm implementation I am aware of that has a limit is SDBM on Solaris,
> > and while the limit is small enough to be annoying, it's larger than 256
> > (although I don't remember off-hand what the limit is)...
> 
> I missed the start of this.
> 
> The DBI modules (parse and write spreadsheet AFAICR) have a 256
> char limit in them for excel.  DBD::Excel calls them, so it has
> the same limit.  You need to hack the pm to raise the limit, at
> least on write.  That's next to impossible to maintain if you
> are using a package manager (eg rpm or deb).
> 
> The amount of data one can enter and save into an excel field in 
> one recent version appears to be about 15362 chars.  Might be 
> version specific.
> 
> At any rate, counting on more than 256 when the perl modules don't
> provide more is asking for trouble.  The data is silently truncated.

This is not true. I cannot characterize all versions of Excel (and Gnumeric),
but the import/export works fine with the ones I mentioned at arbitrary
sizes. I provided a few options, and make the proper tweaks in the
objects at the time of import or export.

Neither uses DBD::Excel.

-- 
Red Hat, Inc., 3005 Nichols Rd., Hamilton, OH  45013
phone +1.513.523.7621      <mheins@redhat.com>

Being against torture ought to be sort of a bipartisan thing.
-- Karl Lehenbauer