>>>Change connection string - done! No recompile or anything required. Like how simple can it get right ??? hahaha
>
>Except that you've run into a problem. ;-) Plus you have a security issue with database connection settings stored in the clear in the dbc on disc. And you risk dbc contention issues. If you don't like USE ... ALIAS, the other option I mentioned was to use xCase to create a dbc with views for local tables and a dbc with views for remote tables. Once you have the correct dbc open there is no programmatic difference. You can put the RV connection string into an encrypted ini file on the server so the app can decrypt it and create the connection for sharing, before you open the RV dbc. No contentions. No connection settings stored insecurely in a dbc on disc. If you use xCase it'll be much easier to keep your local tables and SQL Server synchronized as well, including the views against them.

hmmm..well I ?think? I have an answer for all that:

I don't have dbc contention issues because I keep the dbc on the workstations.
No security issue because the dbc connection settings are not storing the password - that's saved in ODBC driver.
dbc on workstation has only remote views & connection string
No local views means that VFP never has to open VFP tables in datasession (remote views dont do that)
No need to maintain multiple DBC's.
No need to xCase