>Progressive? With FP2.0 we moved *away* from DO WHILE loops to SCAN for >database iterations, because SCAN was optimised and worked better. Now we >"progress" back to DO WHILE loops using ADO.

I will bet you anything that I could write a block of code with Do While - that is just as fast as Scan, EndScan. Lets see which is more work:

Seek 123
Do While x = y
Skip 1
EndDo

Or

Seek 123
Scan While x = y
EndScan

Yep, Scan...Endscan eliminated one line of code - the skip. Boy, how will I ever live with out that. Sorry, with getting the flexibility of ADO, not being able to use Scan...EndScan really does not seem like that big a deal to me.

>You will understand why some FP people might have an issue with this- if ADO >is based on FP, then it is *very* fair to wonder why we are reverting to >constructs abandoned in FP years ago.

I think I just demonstrated that there is not a big issue. However, ADO is not meant to be a replacement for native data access in VFP. I am on record quite a bit saying that. However, if you need some functionality - say passing an updateable recordset to different objects, or an office app, or something else, then consider using ADO. If you don't need to do that sort of thing - then use VFP cursors.

>Finally, If you could just reassure me that ADO allows expressions and >functions in the DO WHILE statement, as well as memory/object scatters etc >that make VFP database development so productive, then that would be a big >help.


Do While is a construct in the language, not ADO. That said, you can wrap an ADO recordset with Do While...EndDo for navigational purposes - and use values in the recordset fields as your boolean expression.

With regard to the second part - the stuff about memory/object scatters - please do not tell me you are doing Scatter/Gather Memvar...... If you are referring to buffering, ADO's buffering is practically identical to VFP's. There is both Row and Table Buffering.

Sorry to say, but there is no Scatter and Gather methods with ADO<g>