>Not if they are defined in a common dbc.

If you are going to hand-code them, why not use SPT instead. At least SPT scales. And behind the scenes, that is what RV's are anyway..

>
Singular controls. But VFP grids don't bind to recordsets. This is a real factor. In many cases, an ActiveX grid is not a viable alternative.
>

The ActiveX OLE-DB Grid Control works fine. I disagree. It is a viable alternative. The grid control is as flexible, if not more so than the native VFP grid. Certainly, it is has far less quirks.


>
Who says that you can't use SPT in conjunction with RVs?
>

I did'nt. Then again, if you are going to use SPT, you might as well not use RV's at all. RV's limit, they don't expland your capabilities.


>
RVs work fine for what they were designed for: quick and dirty updatable access to back-end data. They have their place, IMO, as does SPT.
>

For most production servers, the words "quick and dirty" don't apply. Those words might apply to a test/staging server, but not to a production server. And, if your updates consist of affecting serveral hundred thousand records, no, RV's don't scale. In those cases, a stored proc is a far better way to carry out those sorts of operations.


>
In many (most?) cases, they don't need to. Conversely, SQL Server doesn't scale down cost-wise to the level of use that dbfs fit the need for.
>

Scale down? Can you say MSDE or Jet? Yes, SQL Server scales down just fine. DBF's are too open for many situations. That is not to say that DBF's are not flexible, don't have a place. But, their place is becomming increasingly more and more limited. MS themselves, on the record, will tell you that DBF's are not a preferred data store. If you need security or robust upsizing capabilities, Jet often will be a better alternative for you. If you can sell DBF's, great. It is important for many to realize however that DBF's, in many places, is not an acceptable storage mechanism for data.


>>DBF's are not substitutes for SQL Server data - period.
>
>Agreed. They serve two different needs with some common ground.

Well, that is my point. Any discussion that treats SQL Server and DBF's as equals is inaccurate..