My application is some kind of a report writer over the web, but the final report (rather its cursor) is large. I found the greatest performance hit was to transform the cursor into an XML and even worse the XML back into a cursor. That's why I wanted to stay with DBF if possible and use the EncodeDBF mechanism. In this scenario, doesn't it make sense to stay away from XML as a transport mode over the wire?


>In general I think it's a bad idea to pull large amounts of data over the wire ever. THe only exceptions to this should be things like reports that need all the data and even those could probably be run on the server and then just ship the result back.
>
>Web Service/wwHTTPSQL etc. - it doesn't really make a big difference because the data is shipped over the wire as XML either way.
>
>FWIW, I did performance testig on this stuff quite a bit and it turns out that data size and performance of XML was FASTER in most common scenarios than trying to use the EncodeDBF mechanism.
>
>Binary DBF files usually bloat more than the same XML data would due to the whitespace.
>
>If you own Web Connection you can run the distributed app sample application and try this out and check the timing values yourself as you can easily switch between transport modes (VFP XML, wwXML, Encode/DecodeDBF).
>
>The sample is also online, but you can only access the sample data that's there which is small.
>
>http://www.west-wind.com/wconnect/wwhttpdemo.app (requires VFP 7.0)
>
>+++ Rick ---
>
>
>>
>>Thierry
>>
>>
>>>You cannot do this by default because VFP lacks the datatypes to return a binary stream in SafeArray format and properly type it that way. VFP lacks an array COM return type.
>>>
>>>I haven't tried this but this should work: You can return the result using CREATEBINARY() (which creates a byte array). Set the return type to string, then change the WSDL and WSML file to return Bin.Hex data which will properly encode the binary string into Base64 (which BTW bloats too).
>>>
>>>I would be very careful about this approach however because not all clients will be able to use this data automatically.
>>>
>>>XML is a much better choice and if you're passing too much data back and forth that it's too slow you might want to reconsider how you are serving the data. If a Web Service sends back data that takes more than a second to convert into XML it's probably sending way too much data back for a distributed application.
>>>
>>>+++ Rick ---
>>>