>>>When I try to open a table in vfp(that worked fine yesterday), I get not a table message. Table opens fine in excel. I don't realy need the data contained in this table because it is just a holder db, but I would like to retain the structure without rebuilding it. Any info or advice would be appreciated.
>>>
>>>Bob Mclintock
>>>IBC Financial Data
>>>Ashland, MA.
>>My experience with 'Not a Table' is sharing between VFP and FPW. The reason is that any change to table ( DBF ) structure in VFP will cause memo file pointers to change to 4 bytes from the 10 bytes used in FPW. Thus, FPW can no longer reference such tables. But, you said you were only dealing between VFP and ExCel, right with no backward referencing into FPW?
>
>I was only trying to open in vfp3.0, where table was created. Could opening in 5.0 or fpw cause a problem? This table is available to many developers so I have no way of knowing what actually was done with it. I just opened in Excel after I couldn't open in any version of FP.
I did a quick check using VFP 3.0 to 'use' a free table created in VFP 5.0a, and got no problem -- I still think problem must be some incompatibility in byte 0 where the table type code is stored in a free table, some values are procesable, some are rejected as 'Not a table' depends on the language / version. Some time back, I wrote a UDF for a customer that examined the free tables in their mixed FPW / VFP environment and returned a logical value if the table could be shared across languages -- VFP 5.0a will 'use' FPW tables, but not necessarily the other way around -- basis of my analysis was the memo file pointer length -- 4 byte pointer is VFP only, 10 byte is FPW / VFP sharable. ( basis of analysis is afields() function ).