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

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

Ok, weird list problems I apologize if that post twice...

The thought occurred to me, there seems to be one byte at the end for each 
8 columns as would be the case in a bitmask. So, 1-8 columns 1 byte, 9-16
columns 2 bytes.  I have not tested this theory yet, but if anyone has
conflicting data let me know.

I believe I've found the required field also.  In text types (only) byte 4 of
the 18 byte column records has a 1 to denote that the field is required.

And again the memo field has upto 244 bytes (256-12byte overhead) inline
with the data and additional should go to an overflow page, but I'm not
sure how all that works yet.

So, all the problems are solved, we just have to code it...which won't be
until at least tonight (EST) if I'm doing it. Otherwise patches are
appreciated :-)


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
>