Re: [mdb-dev] counting fixed / variable data rows

[Brian B. <ca...@um...>]

Karl,

All three of these fixes are in CVS and I can do a mdb-export on the sample
database you sent.  There seems to be one lingering problem (null memo
fields come up "oops", but since we have no explicit support for NULLs, I
think that's not too bad).

The only big mystery left is why upgraded databases don't seem to start data
on the correct page...if we can fix that one, I'd say we have something
usable.

Brian

On Tue, 14 Mar 2000, Brian Bruns wrote:

> 
> On Tue, 14 Mar 2000 kn...@gr... wrote:
> 
> > I've encountered a problem I haven't been able to solve yet.  Here's a
> > relatively small instance.
> > 
> > A couple things - the variable string data doesn't seem to quite be
> > laid out in the same manner as other data.  Some of the variable
> > length data in the middle exists, while other data exists via some (as
> > yet unclear to me) pointer mechanism.  Also, the current code
> > calculates the number of variable columns all wrong in this instance.
> > 
> > I have hard-coded a 5 in (4 varchar fields and one "memo" field, which
> > appears to be somewhat equivalent to a varchar (64K)) - this could be
> > wrong, but is closer than the value that comes from the code or the
> > HACKERS file description.  I was wondering whether it might not be
> > more beneficial to parse the data by column (0 .. 11) and select a
> > data parse based upon column type, rather than parse by column type
> > (fixed columns first, then variable columns), but I haven't been able
> > to get past that pointer to the varchar data (in ?? below).  The
> > actual data does start 31 (decimal) bytes from the end of the data,
> > but I can't map a length, unless it's that <0c> sitting at the
> > beginning of the data.
> > 
> > The access data:
> > 
> > 	82,99,8,"UPDATE_ID_LEN","1996-05-19-00.00.00.000000","1996-05-19-00.00.00.000000",,1,1,1,0,"None"
> > 	82,100,26,"UPDATE_TMSTP_LEN","1996-05-19-00.00.00.000000","1996-05-19-00.00.00.000000",,1,1,1,0,"None"
> > 	82,101,40,"DEPT_NM_LEN","1996-07-11-00.00.00.000000","1996-07-11-00.00.00.000000",,1,1,1,0,"None"
> > 	82,102,3,"TTL_TP_CL_LEN","1996-07-11-00.00.00.000000","1996-07-11-00.00.00.000000",,1,1,1,0,"None"
> > 	82,6291458,4,"SIC_TP_LEN","1998-09-08-17.12.36.000000","1998-09-08-17.12.36.000000",,41,41,1,0,
> > 	82,15728641,3,"STD_ENTR_CL_LEN","2000-02-15-11.48.09.000000","2000-02-15-11.48.09.000000",,82,82,0,0,
> > 
> > prtable reports (correctly):
> > 
> > 	number of datarows  = 6
> > 	number of columns   = 12
> > 	number of datapages = 1
> > 	first data page     = 30
> > 	column 0 Name: VERSION              Type: Integer(2)
> > 	column 1 Name: ID_VALUE             Type: Long Integer(4)
> > 	column 2 Name: MAX_LENGTH           Type: Long Integer(4)
> > 	column 3 Name: IDENTIFIER           Type: Varchar(30)
> > 	column 4 Name: CREATE_DATE          Type: Varchar(26)
> > 	column 5 Name: LAST_MOD_DATE        Type: Varchar(26)
> > 	column 6 Name: EXPIRY_DATE          Type: Varchar(26)
> > 	column 7 Name: DEFINED_VERSION      Type: Integer(2)
> > 	column 8 Name: LAST_MOD_VERSION     Type: Integer(2)
> > 	column 9 Name: STATUS               Type: Integer(2)
> > 	column 10 Name: DESCOPED_IND         Type: Integer(2)
> > 	column 11 Name: DESCRIPTION          Type: Memo(0)
> > 
> 
> Ok, three things seem to be happening here. one is that there is an extra pad
> character at the end of the row (I wish I could figure out the rules that
> this follows...it seems to happen on some tables and not on others...anyway 
> you'll see it on page 0x001f of the mdb file you sent me, rows end 0xbf 0x0f
> instead of the normal 0x0f).  So, that's one problem.
> 
> Problem two is that only INDENTIFIER and DESCRIPTION are treated as variable
> length (perhaps the required field controls this?)...somthing to look at
> anyway, but no answers as of yet.  I can't find anything in the column
> definition that my be used, but I'll keep looking.
> 
> The third problem is the memo field preprends some info on the front of the
> text. 12 bytes it appears... the first 2 seem to indicate length (0x04 for
> "None")
> 
> Brian
> 
> 
> _______________________________________________
> mdbtools-dev mailing list
> mdb...@li...
> http://lists.sourceforge.net/mailman/listinfo/mdbtools-dev
>