We use RV's for the same reasons.

One thing I learned recently: unless you put the schema name in the table name (select * from dbo.mytable), SQL will redo the view plan for every user. I got that from one of my SQL Server feeds. Fortunately we generate everything (starting from xCase), so as of the next release, that's what we'll have.

Hank

>>>OK. I never used a VFP View.
>
>I did. In the end, a VFP Remote View (RV) is a wrapper around SPT being passed to a backend, same as a CA, and shares the performance and other attributes- including that for at least 15 years, a properly parameterized VFP view gets cached by SQL Server making subsequent queries as efficient as a SP needing thousands of iterations IME to show a measurable difference. There is a slight hit opening the RV especially in a shared DBC but then performance is likely to be very good with the parameterized and cached queries.
>
>One significant RV feature is setting of field types. Various versions of databases do or don't have date or bit field types for example, and a SQL Server text binary field may be best handled as a VFP general field or a memo binary. Set this at design time and it's done, whatever database is sitting back there. Similarly, select properties to enjoy very efficient and inexpensive change management by the RV.
>
>Which is of course another benefit of the VFP RV, that it can be seamless against multiple backends. Include a Views DBC in your app and use CONNSTRINGs to get a handle and it's seamless from there. Use a CA and you need at least some knowledge of the underlying stuff and will need a wrapper if you are considering more than one backend or even possibly more than one database version. Plus there are the reported CA problems against MySQL and Postgres as well as reported troubles against any Linux database where Case suddenly matters, so your hand-coded SQL for the CA needs to be spot on. If it's a MS-only solution, I guess that doesn't matter.
>
>I agree that the CA allows edits of the WHERE clause and benefits on datasources for grids, but people need to be careful: if you concatenate the WHERE clause rather than using parameters, you lose the cached query benefits and risk inadvertent introduction of SQL Injection risk. Whereas a parameterized RV is immune to SQL Injection.
>
>IMHO RV and CA both have value, but RV is extremely accessible allowing creation of working Views in moments. It meets the KISS principle and therefore tends to be considered old-fashioned in these Rube Goldberg days. If a RV does what people need then it ain't broke and doesn't need to be fixed IMHO.
>
>In this case comparing to SQL Server views rather than Remote Views: as noted, SQL Server now caches and offers very good performance for precompiled parameterized queries. Depending on whether you own the database, it may be simply more expedient to express as SPT or a CA or RV than trying to get database changes past a DBA, especially if used for reporting needs where users may wish to tweak things.