Perhaps you can create two DBCs.

One DBC will have remote views pointing to SQL Server tables, for example rv_table1.

The other DBC will have local views pointing to local FoxPro tables, for example lv_table1.

You could even name both views the same (v_table1) and forget about the "r" and "l" prefix. If you DBCs are named local and remote then the "r" and "l" are irrelevant in your views.

As soon as your user lanches the application you will need to have some kind of mechanism to have him/her select whether they want to work with local or remote data. After than, your program will open the right DBC and thus the right views.

I would recommend you to use views for your local data. This way, you won't see a change when working with remote data, 99% of your programming will be the same.

>Hello,
>
>I need a quick "pointer in the right direction" before I head off down the wrong path.
>
>I need to access remote data from SQL Server and be able to work with a copy of this data when working standalone. Here is my guess at the steps in doing this (assume there is one table in the database named table1):
>
>1. Upsize the current FoxPro database to SQL Server. This results in "table1" (a view of the remote data) and "table1_local", a local foxpro table as before the upsize.
>
>2. If the user wants to work with remote data, do a "use table1" and do tableupdates, tablereverts, etc. to manipulate the data.
>
>3. If the user wants to work locally, copy the remote data to an empty "table1_local" and then create a view of this data which can be treated the same as the view of the remote data.
>
>I am obviously trying to keep the bulk of the code from knowing which view it is working with.
>
>Thanks for any suggestions,
>Pat