>>Eric,
>>
>>Thanks for the reply. Ed had a similar solution but I don't have to know the number of fields in the table before hand. The only way to get the number of fields in the table would be to open the table with USE. So I would still have to open the table with your solution which I was initially trying to avoid.
>>
>
>Not true - look up the topic Table File Structure (.dbc, .dbf, .frx, .lbx, .mnx, .pjx, .scx, .vcx) in the Appendix of the Programmer's Reference (it's in the VFP Help FIle). The basic stricture of the header is there.
>
>Since only VFP tables (tables whose first by is 0x30 - 48) can be members of a DBC, there's a simple formula based on values in the header to compute the number of fields. The offset of the first record is contained as an unsigned short integer at byes 8 and 9 of the file. The following formula correctly computes the number of fields in a table without doing a USE, assuming that it's a VFP table, or any of the non-wierd xBASE variants:
>
>

#DEFINE BACKLINKSIZE 263
>#DEFINE FLDLISTTERMSIZE 1
>#DEFINE PREFLDLISSTRUCTSIZE 32
>#DEFINE FLDENTRYSUBFLDSIZE 32
>#DEFINE TYPE0x30HEADERSIZE BACKLINKSIZE + FLDLISTTERMSIZE + PREFLDLISTSTRUCTSIZE
>#DEFINE DBASEFOXBASEFOX2XHEADERSIZE FLDLISTTERMSIZE + PREFLDLISTSTRUCTSIZE
>nFH=FOPEN(cDBFToTest)
>cStrBuff = FREAD(nFH,10)
>nFirstRecOffset = 256 * ASC(SUBSTR(cStrBuff,9,1)) + ASC(cStrBuff,10,1)
>IF LEFT(cStrBuff) = CHR(0x30)
>   nNumFlds = (nFirstRecOffset - TYPE0x30HEADERSIZE)/32
>ELSE
>   * this is a bit presumptuous, but you might get away with:
>   * nNumFlds = (nFirstRecOffset - DBASEFOXBASEFOX2XHEADERSIZE)/32
>   * or the right way is to walk the list of subflds until encountering a 0x0D
>   =FSEEK(nFH,PREFLDLISTSTRUCTSIZE,0)
>   nNumFlds = 0
>   DO WHILE ! FEOF(nFH)
>      IF LEFT(FREAD(nFH,FLDENTRYSUBFLDSIZE),1) = CHR(0x0D)
>         EXIT
>      ELSE
>         nNumFlds = nNumFlds + 1
>      ENDIF
>   ENDDO
>ENDIF
>=FCLOSE(nFH)

Ed,

I should read more before I write. Thanks for correcting me.

So the Table File Structure topic got me thinking... How about changing the header structure in the destroy of the data_space object so the table wouldn't even be reconized by VFP, Dbase or other applications and then changing the header structure back on the startup of the data_space object.

Just thinking of an extra layer of protection for the data. Any comments?

Bill