gbcpastor said:
checked the header and it was correct for what would be needed for the access data engine
Well, what is this first byte but a promise? Another example of insufficient compatibility is Excel 2007 outputs an Excel 97 compatible binary XLS format, yet VFP can't append from such files, but Excel 97 can open it. The question is: What kind of compatibility tests are actually made, and, well, the major intent of fo2x files is to be readable by legacy foxpro, not by the jet engine or other drivers that are capable to accept some dbf format.
You overlook the option to act from VFP and put data into anything else Raptor can easily access. It's simple to put data into Access databases, no matter if old mdb files or modern accessdb databases, because VFP can use ODBC and OLEDB providers and work on remote databases, also you can access all VFP dbf formats VFP9 supports and that is a lot including legacy formats - with the VFP OleDB provider.
One question I have is why your IT guy isn't here to ask what can be done, there are tons of possibillities aside of the nonworking ones you already tried and retried in every way. And actually VFP is bad in creating CSV as soon as you have to eport Memos.
Access can also make use of both ODBC or OleDB, it's just not possible to have a linked table via OleDB provider, but you can program VBA which uses ADO, which can use the VFP OleDB provider. You're focussing too much on the Jet engine as the only viable option. Of course you imit yourself to what that can do. You're underestimating your options. And since you're fine with making a dbf copy to fox2x format, you should be fine to not have a linked table access (i.e. updates on this table also are updates of the original dbf file and so data is actually shared, not exported/imported), so why not make use of something - anything - that Raptor can see. There should be tons of possibilities and insisting on the one you always used is not an option that brings you forward, obviously. What and how exactly VFP creates fox2x dbfs is not open source, i.e. there is no VFP code that you could mend to make it a jet compatibe dbf format, but who cares if there are other options? Get ralistic. Nobody here will dig into the file formats to know which bytes would need to be changed, I doubt it would even be just a fix of some bytes, you'''d need to write a whole export and then it's much easier to do that to export data inclduing memos to CSV.
Chriss