Erik...

>
Cursor operations have little to do with DBFs. Many VFP architecture scenarios deal with cursors but do not deal with DBFs.
>


A cursor is essentially a DBF in memory... Do you disagree with this?


>
This could not be further from the truth. I know that you are partial to the Recordset as a data package, but you should be aware that there are many scenarios that are better suited to other means.
<

There are many scenarios better suited to other means? Do you mean that there are scenarios where a VFP cursor is better suited to the task? I would agree with you here. Then again, my point was not that sweeping. You have attempted to make my point more sweeping that it was intended to be.

For some hard core data munging, a VFP cursor is a great way to go. Then again, most of what I discuss does not deal with data munging...

If you have some scenarios that are non data munging related, I would be happy to discuss those with you...


<<
I should also point out that it is easy (trivial?) to convert ADO recordsets and several different XML formats into cursors.
<<

Yes....so what does this have to do with the topic? Who cares about getting data into a VFP cursor? That may be a point you wish to bring up. Certainly, it is not a point I raised...


>
Intensive client side munging (or middle-tier munging) with an ADO recordset is painfully slow, and much better suited to a cursor.
>


Point being that one should not be doing client-side data munging. And, if the result set is as small as it should be, speed should not be an issue...< s >..



>
And if you use cursors (like I do), whether or not you use DBFs (like I sometimes do), the new commands are really nice.<
<


Good. FWIW, I don't see where the IN clause is THAT big a deal...< s >.. But if you are happy, congrats!!

< JVP >