>If the database is a FoxPro DBC - VFP does NOT open the underlying tables along with the remote views.
>If the database is a FoxPro DBC - VFP DOES open the underlying tables along with the local views.

I think with remote views, it still access the tables, but just does not open it in your application, but rather in the ODBC driver for VFP.




>>Point of clarification -- if the database is a FoxPro DBC, VFP does open the underlying tables along with the remote views.
>>
>>>I originally considered doing it that way. Problem with using the local views is that VFP still opens the tables with local views - not with remote views - which is why I use the remote views.
>>>
>>>>I don't agree with that. Use local views for VFP tables, then just change a property setting to switch to remote views. Easy, peasy. And you get all the speed and capabilities for VFP tables when you use them.
>>>>
>>>>>Yes that's true. I've preached before about using remote views to hit VFP tables so that all you have to do is change the connection string and then have all your remote views point to something else like SQL Server or Oracle. Of course most people are not going to create their VFP apps that way from the onset. Even so I would *think* that even if you had to deal with such an issue that it would probably still be less time consuming than doing a total re-write to something like C#. I guess it would require doing an analysis to determine if it's worth doing and its going to be different for every case.