[mdb-dev] possible bug in mdb_crack_row (when using mdb-export)

[Alex H. <ba...@gm...>]

Hi,

Im trying to export a JET4 mdb file. However some columns seem to have
NULL values when they should be otherwise.  The column is a long
integer and here is the attempted export with MDBOPTS=3Ddebug_all (and
MDB_DEBUG set to 1 in mdbtools.h)

Row 86 bytes 2965 to 2977
0b95  03 00 10 00 00 00 3c 00  d8 0c 01 00 07            ......<......
bitmask_sz 1
row_var_cols 1
row_fixed_cols 2
sarg test passed row 86
0b95  03 00 10 00 00 00 3c 00  d8 0c 01 00 07            ......<......
16,60,

where the expected out put is
16,60,6882

The problem seems to be it detects row_var_cols when infact they are
all fixed rows. If i apply the following patch

--- write.c.old 2005-11-17 12:57:32.000000000 -0700
+++ write.c 2005-11-17 12:55:26.000000000 -0700
@@ -173,11 +173,11 @@
    nullmask =3D pg_buf + row_end - bitmask_sz + 1;

    /* read table of variable column locations */
-   row_var_cols =3D IS_JET4(mdb) ?
-       mdb_get_int16(pg_buf, row_end - bitmask_sz - 1) :
-       mdb_get_byte(pg_buf, row_end - bitmask_sz);
-   var_col_offsets =3D (unsigned int *)g_malloc((row_var_cols+1)*sizeof(in=
t));
-   if (table->num_var_cols > 0) {
+   if(table->num_var_cols > 0) {
+       row_var_cols =3D IS_JET4(mdb) ?
+           mdb_get_int16(pg_buf, row_end - bitmask_sz - 1) :
+           mdb_get_byte(pg_buf, row_end - bitmask_sz);
+       var_col_offsets =3D (unsigned int
*)g_malloc((row_var_cols+1)*sizeof(int));
        if (IS_JET4(mdb)) {
            mdb_crack_row4(mdb, row_start, row_end, bitmask_sz,
                 row_var_cols, var_col_offsets);


Then i get the expected output.  Here is the same row with the same
debug options on.

Row 86 bytes 2965 to 2977
0b95  03 00 10 00 00 00 3c 00  d8 0c 01 00 07            ......<......
bitmask_sz 1
row_var_cols 0
row_fixed_cols 3
sarg test passed row 86
0b95  03 00 10 00 00 00 3c 00  d8 0c 01 00 07            ......<......
16,60,68824

Im not sure if the above patch is really the fix or more just a work
around that will break if you actually have var_cols.  Also i noticed
all of the mising values seem to be above 66000 (I m thinking maybe
65535?).  But there are about 3,000 rows with missing values out of
about 45,000 rows so i have only looked up a few. So far it has always
been the last column in the row as well.