>Jim:
>I did as you suggestted, but it didn't help. The file only has 1 record without an index. Contact me at mwtimpe@yahoo.com and I will send you the file.
>
>I've been seeing this problem in other tables in our system. As long as we don't try to change the structure of the marginal table, everything works fine. However, when Stonefield attempts to alter the table, I get an error. I probablly have one of these tables that I could send you as well. I used a hex editor to look at the table and found a field "CODEDATA" followed by 0001. When I changed the 1 to a 0, Stonefield was able to do it's thing! (VFP 7.0 SP1)
>
>Almost all of our tables are former Clipper tables that used Comix indexing.

Mike, Cripple..erm...Clipper had some extended field types that are not directly supported by VFP, such as character fields larger than 254 characters that are not memos. These can cause you considerable grief when the tables are accessed using VFP; in addition, while I'm not familiar with Comix indexing, I know a number of the Clipper supported index schemes are not translatable/usable in VFP, and they put markers in the fiel header than can confuse VFP.

I've had a good deal of success using CodeBase's ActiveX/COM and ODBC drivers to handle these variant tables from within VFP; they work in lots of situations where VFP won't, and will permit a VFP app to work directly with Clipper data which is maintained live, in parallel with existing Clipper acts, using its fields and tables directly. I've also used their product for ADO connectivity in a VB app with relative ease. CodeBase's COM and ActiveX components work in VFP 6 and 7 at least, and their ODBC drivers can be used for DBC-based RVs and SPT as well as ADO.