Mike

>Comparing apples to oranges

You are right, but it isn't my example...

>Using ADO there wouldn't be a FOR condition because the SQL statement on the ADO object would have already retrieved the desired records, so the code in the ADO object would be something like

DO WHILE NOT This.Eof
This.MoveNext()
ENDDO
>

Exactly! And that is the point I wanted to get to. SCAN...ENDSCAN is most useful against unordered tables or where there is a partial index. When I posted my open question, the fact I wanted to raise was that once developers move to parameterised views, SCAN FOR becomes less useful anyway. So the point is moot. Some of the possible uses (eg harnessing a "generic" lookup for multiple purposes) are eliminated because ADO is programmatic so there is no disadvantage to carving an ADO query on the fly that contains just the records you want.

One *real* difference I see is that of SCATTERing and manipulating.

IMHO using ADO for FP people is no big deal, as long as (as you say) you compare apples with apples. BUT, and this is a real BUT, I can see VISIBLE PERFORMANCE DIFFERENCES in many cases, especially where VFP can use SCATTERS, indexes and data functions that span lines, while ADO cannot. Whether this will make a difference long term is hard to say- MS will optimise ADO.

You are right, we need to move this discussion away from primitive "see how easy it is to do this pointless example!" to real-life examples of how some things in FP are better expressed with SQL Views anyway, and how ADO *could* have been useful to us if only we could databind properly and use concurrent methods...<g>

Thanks for the technically-oriented post,

Regards

JR