>>>>
>>>>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.
>
>Explain ??? Kevin I can't believe you still need an explanation for this. SQL would open the table if it's not open already.

I have stated my reason for not doing this below, it slows..it...down, it is not any faster, no gain..

>
>
>>
>>>-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...
>
>
>SET PATH ??? Who said 'SET PATH'. What happened to name expressions. But I even don't understand why you need those use ... Tables are simply used and not referenced at all. IOW I didn't understand the need for empty use series there + the need to close client,property,foxguids tables each time near the bottom of loop. Actually I thought you found a way to express :

What difference is using SET PATH and name expressions going to make, it's still performing the same tasks.

>for ix=1 to 7 && instead of 7 using alen()
>open 3 tables but never reference them
>do some select
>insert...
>close tables used in SQL
>endfor

If you believe that will make a difference I'll happily try it...

>
>>
>>>-'DISTINCT' in SQL sounds to be unnecessary and a good way to slow down.
>>
>>It's in the C# code as well, next...
>
>So VFP code should be exactly same :)

Um, yes if you want a fair comparison, how can you make a valid comparison when the processes aren't matched?

>
>>
>>>-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?
>
>Oh and it's now in the way it's supposed to be ! It looked like for 'test only' code.

My point was why is it necessary to have such an in-depth knowledge of VFP to get it doing something a little bit faster, when the current implementation fits the bill?

>>
>>>-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.
>
>Well with data at your hand you should build better :
>

>Select Cl_Ref ;
>  FROM Client ;
>  where Cl_Sname = "LAWRENCE"  And ;
>  Pr_Code In (Select Pr_Code From Property) And ;
>  Cl_Ref In (Select PKey From FoxGUIDS Where FoxGUIDS.Table = 'Client') ;
>  Into Cursor temp nofilter
>

Going on past experience using IN I'm not keen on it, however, I'll try it by all means.

>
>>
>>>-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.
>
>Hmm when I do that results are accepted worthless and the thread is left to death.

I never actually saw you post any results with a small case study.

>
>>
>>>
>>>>
>>>>>
>>>>>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.
>
>Cetin