>>
>>I meant the results of the tests, not the code. And whilst on that subject no-one has actually come up with a more efficient effort that has affected the results to swing VFP in favour, until then I don't see how my code is SO inefficient.
>
>From a lot of lines I can spot inefficiency. Let's summarize :
>

>USE Z:\Useful\Offices
>
>SELECT *;
>  FROM Offices;
> ORDER BY 1;
>  INTO ARRAY laOffice
>
>USE IN Offices
>

>-Why a use that has no purpose ?

Explain.

>-Why * when you only deal about first 2 (obscure what they're) fields

The table only contains 2 fields. BTW this isn't being timed in my latest tests.

>
> laOffice(o, 2) = ALLTRIM(laOffice(o, 2))
> USE (laOffice(o, 2) + "client") IN 0
> USE (laOffice(o, 2) + "property") IN 0
> USE (laOffice(o, 2) + "foxguids") IN 0

>-Same unnecessary use series

OK, how would you do it? If I SET PATH and rely on the SQL it slows the query down...

>-'DISTINCT' in SQL sounds to be unnecessary and a good way to slow down.

It's in the C# code as well, next...

>-Only cl_ref is needed and unnecessarily * there

Again, it's in the C# code because it needs to be....

>-Is SQL really needed. If yes is it the way you'd write it. ie: Why 'Client' is in join when it it might be in 'where'

You really are clutching at straws here, how many time shall we revist this code in order to get it to work how it's supposed to?

>-Are you sure that SQL wouldn't perform better if used 'in' queries instead

Wouldn't have thought so, but if you give me the query I'll try.

>-Scan..endscan is inefficient but as you said not worth to think of for small sets

Correct.

Wish I had the data or at least what it looked like.

I'm sure you can manage to get at some data somewhere.

>
>>
>>>
>>>PS: Even if you let them die, I spent time writing the code and thought at least deserved a single word.
>>
>>And I spent the time writing it in the first place, and everyone had their say, it wasn't just "ignored".
>>
>>The fact of the matter still remains, all I've seen is people failing to accept (or even acknowledge) that the OLE DB may actually be more efficient than direct-access in certain scenarios - it's the same old story - "Oh, it must be your in-efficient code"...funny how I don't have to revisit the C# code umpteen times.
>>
>>Kev
>
>Still you're missing the point and connecting it with OLEDB vs VFP native access. It's the same team that wrote both. What I'm trying to say in .NET in the time (plus miliseconds) you get the data to work on VFP finishes processing. Your other thread shows that neatly.