Re: [mdb-dev] Segfault reading JET3 mdb

[<br...@br...>]

This is a know problem, well sort of.  It happens with deleted columns
(create a table, populate it, drop a column).  If you compact/repair
the database in Access then all is well, I just haven't figured out
how Access handles it yet.  (Imagine create table, populate, delete
column, add different column....problems).

I had considered simply aborting on finding this condition, but I'd
really like to fix it.

The transition to crack_row still needs a bit of work I think.  It's
there to clean up that awful data.c stuff, and to support writing via
it's partner mdb_pack_row().

If you wouldn't mind, post your patches to Sourceforge so I can keep
track of them easier.

Cheers,

Brian

On Mon, 2 Feb 2004 09:32:11 +0000, Will Newton wrote:

> 
> 
> Currently I get a segfault when reading a JET3 database I have
> here. Unfortunately the file is rather large and proprietary, so I
> can't really make it available. It seems that "mdb_crack_row" is
> returning a "num_cols" different from the length of "fields" so
> subsequent iteration over "fields" runs past the end of the array.
The
> returned value of "num_cols" is not consistently greater or smaller
> than the length of "fields", it seems like the wrong value entirely
is
> being read. 0.5 didn't do this, but HEAD did.
> 
> The attached patch fixes the problem. Why, I'm not too sure.
> 
> Exporting my database still has problems:
> 
> 1) On certain large tables the text in some fields seems to be offset
> slightly i.e. the start of one field would like like the end of
> another (the last field?). I have these columns:
> 
> id,quote_number,declaration_number,new_renewal,agent_code,long_name
> 17829,"",37124,"41196NEWTUNICKWilliam N","ewbold & George..."
> 
> I have abbreviated the data because the table is rather large. The
> data should look more like:
> 
> 17829,37124,41196,"NEW","TUNICK","William Newbold & George..."
> 
> That is an approximation as I'm not entirely conversant with the
> schema of this legacy data, but it does illustrate the general
> appearance of the bug.
> 
> 2) Memo fields are not being read quite right. WHen exporting a large
> table with memo fields (in fact it is the same table as previously
> mentioned) I get error messages:
> 
> ...
> offset 731000832 is beyond EOF
> offset 419665920 is beyond EOF
> offset 733181952 is beyond EOF
> offset 1090744320 is beyond EOF
> ...
> 
> And ultimately a segfault. It seems the value of "lval_pg" when
> reading non-inline memo fields is incorrect - again it looks like a
> pseudo random value rather than any consistent error.
> 
> 
> These problems may be related - many of the simple tables in this
> database export cleanly. None of the tables with memo fields export
> correctly AFAICT.