>
If you do not agree with my point about refresh(), why not rebut it in the wiki?
<

Because I wan't to deal with it here... If somebody wants to glean the info here, they are free to do so...

<<
To me Refresh() is incredibly useful- especially in a fat client, data bound environment when the ability to refresh a subset of (say) 100 records is a blessing. Whether 100 records "is too many in a C/S environment" is unarguable because I guarantee I can dream up reasons why I need it.

If you have compelling arguments I'll listen, I love to learn, maybe you are right and there is a better way. Convince me.
<<

I thought about this a lot before responding. It then occurred to me to examine the link between Refresh() and RV's. The fact is, Refresh() works just fine for SPT cursors. I had suspected this, but had to verify it.

I agree that Refresh() does present a handy way to refresh those records that have not been updated on the client. Requery() OTOH, does not work for SPT cursors. When you think about it for a moment, this makes sense. Since there is no meta-data to draw on, how would VFP know what CursorSetProp() settings to make. Considering this issue, it is not that big a deal since re-executing the method or function that produced the SPT cursor in the first place is a functional equiv. for Requery().

With this in mind, justifying the use of RV's on the basis of Refresh() is logically flawed since one does not depend on the other.

>
But I can quote examples with giant rows where a RV delivers far better performance than a SP.
<

Far better? Please, quote on...

>
I can't remember that point. I remember the point that use of RVs (and LVs) can make your app backend independent. This *does* matter, especially for broad appeal apps where buyers may have a corporate database standard. Faced with "lose the business" vs "use Sybase" on a big deal, the ability to demonstrate quickly using Sybase is a blessing.
>

Like the Refresh() argument, back-end independence is not in the sole province of RV's. SPT is capable of backend independence as well. Let's remember, RV's are built upon SPT. Therefore, the justification for RV's has to be found on solving a problem or a number of problems. Once must look at this in light of the control the developer gives up. Anytime the developer cedes control to a "black-box" operation, a measure of control and flexibility is given up.

Your tact here is to cite two things RV's allegedly provide (Refresh() capability and back-end independence). These features are found in SPT cursors. If SPT cursor provide marginal extra work in exchange for full control and access to stored procs, why would I box myself in with RV's. My tact in this excercise is to focus on what one gives up by using RV's.

Unless you can show a demonstrable material advantage to RV's, that only RV's have, I, nor should anybody else, accept the pro-RV arguments advanced so far.