Hold on a sec.

Why? XML is plain text, and in returning XML from a COM call the text is converted into a Unicode string automatically. Nothing more required.

I've been doing this for a number of applications without problems.

XML can't contain binary data (specifically CHR(0) and none of the CDATA constructs like ]] ) so that's not an issue either. If you have binary data it needs to be encoded (typically MIME/Base64 is used for that) and the resulting string is still safe to be passed over standard COM interfaces without BinaryWrite() or CreateBinary() in VFP.

+++ Rick ---

>>>>I am selecting records out of a VCX file to return to a client using IIS,wwipstuff.
>>>>When I get the XML on the client and decode it into a cursor, the binary data in the OLE field is FUBAR.
>>>>Any suggesions?
>>>
>>>What code is running on the server to return the table contents? ASP? WebConnection? Are you using wwXML to transform to and from cursor? Any reason you need to use XML for this instead of EncodeDBF and DecodeDBF?
>>
>>I am using ASP and wwXML. I tried to use Encodedbf without luck.
>
>If you are calling wwXML as a COM object from your ASP, you have to return the contents using Response.BinaryRead (wwXMl will have to be modified to retrurn its dataset using CreateBinary). If you are calling a VFP COM object from ASP and returning the binary contents, you have to use VFP's CreateBinary function to convert the VFP string to a Binary string that you can pass back to your ASP script.
>
>All this assumes that wwXMl provides for holding the binary data correctly with the CDATA directive, which I don't think that it handles correctly. I suggest that you use CreateBinary, BinaryWrite and Encode/DecodeDBF to handle this to take the XML confusion out of the picture (even if Rick wrote his class correctly, we don't know for sure that msXML will correctly handle the parsing when it sees the binary data).