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

Hmm. I would rather call a dbf essentially a cursor on disk. But I suppose that is neither here nor there. :-)

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

Sure. The application I am working on (framework, actually) uses ADO to access data in the middle tier, but serves it up as XML, which the client consumes and generally converts to cursors. So I use LOCATE, SCAN, even an occasional SET FILTER. Changes made on the client are translated back into XML, submitted to the server which uses ADO to submit the changes to the backend.

If your statement was not meant to be sweeping, that's cool, I just wanted to raise a counter point or two.

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

My point was that n-tier and the use of cursors are not mutually exclusive, as you seemed to imply.

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

Point taken. But middle-tier data munging is a pretty common need. I know you have expressed that you think much of this should be taken care of in SProcs, but IMO, TSQL is not the best language for this, and I would much rather have a full service language at my disposal.