John

>Why do you see it has a step back? have you run benchmarks to see if you would really be negatively impacted from a performance standpoint? Seem to me you should have some facts in order to make such a conclusion.
>

I don't want to argue semantics... but if you are advised to move away from something and then are advised to move back, then you are, moving, back. What more do you want? "Back" is not necessarily a attacking term. You protesteth too much.

>
about losing Scan..Endscan is not a statement???? Sorry, if you make statements like that, I will ask you to support them. If you don't want to support them...fine. I then reserve the right to gripe about it a bit. >

Well, we are losing SCAN with ADO. What support do you want exactly?

>
The broader issue of losing VFP's DML/Navigational constructs is a big issue. I was hoping to get some insight here - by having you support your assertions. You did not - eventhough I gave you ample opportunity to do so.
>

What more can I say?

>However, you trotted out statements - not questions. I am just asking you to defend your position.

What more can I say?

>Reasonable arguments tend to be backed up by facts.

What more can I say?

>Just show me how you would be negatively impacted by a lack of Scan..Endscan when ADO is the correct solution.

I'd love to discuss this point. The fact is that SCAN...ENDSCAN as a "programmatic" construct can be done different (?better) ways in "programmatic" ADO. This is a good contrast with VFP where SCAN is still useful because much of our data manipulation is not programmatic.

Lest we forget: the example of SCAN vs DO was never mine. I merely responded to it. You then amplified it.

Regards

JR