>>>>
>>>>Well remember first one of your messages doing a simple test comparing speed of VFP vs C# (creating XML tags). Your tests showed VFP was around 6-7 times slower but we showed you it was C# at its best form 3 times slower (excluding the enourmous time just needed the little C# sample to run). I'll try to find the thread.
>>>
>>>Those tests were pretty worthless, I'll admit, that's why I think they should be discounted.
>>>
>>>>>
>>
>>Well that's the point. Those tests were worthless, right. In the same manner the one you showed now is worthless too. Just think 'inside' architecture of a .NET data operation and you'd see practically it's impossible to beat VFP in OLEDB vs native context. If you do it with direct access to VFP table files in .NET then it'd be fairly easy to beat VFP. Hope you get te idea.
>
>Uh, no, these tests are by no means worthless, they are demonstrating data-retrieval from C# and the same thing from VFP. I was interested to see how it stacked up against VFP, turns out the results were surprising.
>
>If you read my latest tests you will see OLEDB compares very well to VFP native data-access, in fact, it's quicker for smaller result sets.
>
>Kev

Well Kevin,
Why don't you then supply us with data so we could build our test cases too.
OLEDB comparing very well to VFP is something expected not surprising. It's important to remember the retrieved data must be maintained some way and if the result set is large .NET needs swapping.
With VFP you have the chance doing things w/o fully retrieving a 'dataset' with .NET no way (unless accessing table files directly).
ie: In your test in results all you need is cl_ref. Then isn't is interesting you do query all fields?
Cetin