That is very true that SP's and RV's cannot be compared. That is why I always try to do this: RV v. SPT/SP.

Whether somebody wants to use SP's or not, that is a separte issue. Before you can get to the SP question, you have to resolve the issue of using SPT's. i.e., If you stick with RV's, SP's are a moot point.

In my last response to you, with respect to different backends, I do compare RV to SPT..

Here is the relevant sentence: "SPT is capable of backend independence as well."

As for data-binding, are you actually trying to say here you cannot data-bind to a SPT cursor, with a grid or otherwise? That is not a difficult task.

As for the wiki page you cite, on one hand, it says this:

RV’s are inherently less secure than SP’s or SPT
FALSE

then, toward the bottom, it says this:

RV’s are inherently less secure than SP’s or SPT
ITS TRUE

IMO, the wiki is not a discussion forum. And yet, that is exactly what this topic has become up there. You cannot reconcile these two statements. One has to correct and the other has to be false. The observer is left to choose, quite frankley, based on suspect information. To me, that is not a very good resource. Although, the page you cite on other fronts, does go a bit deeper in the matter.

The context here is that you are pro-rv and I am anti-rv. I cite issues like performance, security, maintenance, error/exception handling, flexibility, and control. In the last exchange, you cited issues like refresh() and backend independence. The fact is, those two issues having nothing to do with RV's per se. Rather, they relate to to the technology RV's are built upon. On top of that, one can perform data-binding operations just fine with SPT cursors. Yet another advantage you feel is in the sole province of RV's.

In the case of a grid, you simply have to set the recordsource to an empty string, re-run the code that gets the result-set, which has the effect of destroying the old cursor and building a new one it its plac, and finally, re-setting the recordsource of the grid. Otherwise, the attributes of the grid will get screwed up. In the grand scheme of things, this is a minor addition of work at best. So with that said, I have said, I have tried it with SPT and it works just fine. Of course, if you want all of that taken care of for you automtically, check out Dataclas/VFP.


However, since you and others have asked/implied, I will correct part of the record right now on the wiki...







>Dear John
>
>Naughty, naughty. On the Wiki, I clearly compare *SP*s with RVs in the areas you quote. I assume you know the difference between SP and SPT. If so, in portraying a SP comparison as a SPT comparison you have provided yourself with a great "straw man" opportunity, but it's pretty transparent.
>
>To those who are interested, the Wiki to which I refer is http://fox.wikis.com/wc.dll?Wiki~MoreOnRemoteViews~VFP . As you will see, the point that JVP "corrects" about multiple backends is comparing SP to RV, not SPT to RV- actually the Wiki makes the same point that SPT may also be cross platform.
>
>Ditto Refresh(). What I said earlier in the thread was
>
>>>To me Refresh() is incredibly useful- especially in a fat client, data bound environment ...<<
>
>See where it says "data bound?" With a RV you open it and Refresh() and Requery() as needed. Try that using SPT and a "databound" grid.
>
>John, if you choose not to contribute to the Wiki, that's fine, but if you choose to rebut it here, please quote directly rather than translating to suit yourself.
>
>Regards
>
>JR