>
I am using the Mere Mortal framework, which has helped me out a lot with the middle-tier. In the middle tier, the framework makes use of VFP remote views of server data (in my case, SQL Server). The author makes what IMO is a pretty good argument for using VFP remote views: VFP forms and thir controls (Grids, Textboxes, etc) work best with data in VFP format.
>

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

Some problems with RV's

1. Changing your underlying structure will often result in broken RV's.
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.
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.
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.

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.


>>I haven't formed a opinion on way or the other yet. I would really be interested in knowing what other people are doing.


If you pass a connected recordset back to a client, you are consuming a connection that you don't really need until you need to send data back to or get data from the server. And, if you queried the connectionstring property of the recordset's connection object, you would find all sorts of information, authentication, ip address, etc, as a DBA, you would not want published....