Hi Bob..

Good points. Much of this gets directly at the issue of application program/data independence. From a design standpoint, the application should not define data access strategies. IMO, this should be done on the server. That way, one is not bound to a VFP-specific implementation. Yes, one could expose the DBC via the ODBC Driver/OLE-DB Provider. Then again, if the data is ultimately in SQL Server, why not go there. In this case, VFP represents a redundant and uneccessary layer.

I have shyed away from views in SQL Server, most because you cannot parameterize them. Although, you can index them and you can filter them with a Where clause. I should defintitely re-visit that issue.

You can see the code in the DBC with the GENDBC program that is in the tools directory under Home(). But as you say, this is not a big deal. Still, it is nice to see what cursor settings one needs to make if one goes the SPT route.

I would be the first one to use the RV designer if it worked. The fact that it is tightly coupled to the structure and the limited SQL support it has relative to what you can do on the server make compelling arguments for avoiding RV's.

And yes, I agree that if somebody is going to go to the trouble of developing a cleint/server app in VFP, they might as well do it the right way!

While your cite your reasons as a matter of philosphy, the reasons are easily backed up on a technical basis.

Thanks for joining the fray and adding you 2-cents..