>>>I'm still a little confused on how your idea of using local and remote views would actually work. Wouldn't I have to change the control sources? If I have myremoteview.myfield for a control source I'd have to change it to mylocalview.myfield when switching between backends right?
>
>You can USE mylocalview ALIAS myremoteview to avoid this, or have a separate dbc for the remote views. Using a separate dbc for RVs opened with CONNSTRING means you can burn the dbc into your app so there are no dbc contention issues either.
>
>To assist with views against both local and remote tables you could consider xCase which will take care of the details for you- including against Oracle and MySQL if that's useful.

But why would I want to do that when I can just maintain ONE set of views in ONE dbc?

a) One DBC (holds nothing but remote views)
b) One set of views (change connection string in DBC to change backend - that's all you have to do, no recompile)
c) Zero code changes to application when switching backends
d) App is using same set of views - simpler to test and maintain.
e) Still able to use forms' data environment

I just don't understand why you would want to go though all the hassle of maintaining two sets of views and loading up your app with USE blahblah ALIAS realblahblah when all that can be avoided. Plus if one set of views didn't match the other set of views & it creates a bug - now you got a hassle because you have to figure out if it's because the views are different or if it's the code.