>Remote views are riddled with problems. At best, a RV can be classified as an incomplete/buggy wrapper around SQL Passthrough.

To anyone else reading this thread, a lot of this debate can be found at:

http://fox.wikis.com/wc.dll?Wiki~MoreOnRemoteViews~VFP

I prefer a mix of SPT and remote views.

>Some problems with RV's
>
>1. Changing your underlying structure will often result in broken RV's.

The same can be true for SPT. If I used stored procedures, they also must be updated.

>2. RV's don't/can't work with stored procedures - which by far is the most
> most scaleable and robust method of working with remote data.

Agreed. I prefer a mix of remote views and SPT.

>3. RV's don't work in component environments. i.e., you can't pass a RV from
> a component. Rather, you need to convert the data to some other format
> such as XML or an ADO Recordset.

When I move to VB and ASP clients, I think my VFP middle tier can serve up ADO and XML.

>4. Your data access strategy is dictated by your development tool. Rather, it
> should be dictated from the DB server. The role of an app tool should be to
> act as a conduit/passthrough to the underlying logic dictated by db server.

I don't have the expertise yet with T-SQL to do the data-manipulation that I can fairly easily do with VFP. While I have read that T-SQL can do anything, I am not going to invest the next n months becoming a T-SQL guru. I am going to learn it gradually, and move what I can, when I can, to sprocs. And the application I am working on now manipulates a lot of data.

As an example, I am working on a project that uses a company's historical financial data (total assets, total net income, etc.) to determine it's relative worth in the stock market. If the latest record for a company is a quarterly record rather than a yearly record, I have to project the last four quarters to create a projected year.

Then I have to look at each year, compare values to the previous year, and so on, to help determine whether a company is unvervalued or overvalued. I can use VFP cursors to project 4 quarters to a year, and VFP arrays to compare a year to the previous one.

Could someone do all this with T-SQL? Probably. Is it easy? I don't think so.

>If you want to work with VFP cursors, that is fine. Use SPT to render them. Don't use RV's. Solutions built on RV's don't scale from either a performance or maintenance standpoint. The key word here is SCALE.

Scalabilty is a relative term. My VFP middle tier is accessed by one client, a VFP program that calculates each stock's relative worth throughout the day. The results of these calculations are stored in SQL Server. A Cold Fusion gets these results via stored procs. So for my situation, remote views work well.