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

Excuse me. But was'nt you that trotted how bad it would be to revert to using Do...While , since Scan...EndScan does not work with ADO Recordsets. I mean, you did post that ....did'nt you??? Yes, I put code to your post - but you did make the comparision.

Why to stand behind your arguments<s>.


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

Not always. Often, folks make the mistake of:

Scan For
EndScan

Instead of:

Seek x
Scan while x = y
EndScan

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


There is no question that implementing ADO has more overhead than simple memvars. After all, an object is involved. If this is all you are using ADO for in VFP, I would probably not opt for ADO. On the other hand, if you need to pass data to COM Objects or an Office Application, ADO is a nice alternative.


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

Fine, you want to move from the primitive, lets do that.

If you are doing straight VFP data access, do not bother with ADO. If you need to pass data to different apps, use ADO - often in conjunction with native VFP data access.