Because you have to code the lowest common database. You get no benefit from anything added to VFP databases after VFP 6.0. Can you work around this? Maybe. Maybe not. Depends on you business needs. It's a great concept, in theory, but I've rarely heard of it working well.

A better solution really is to have a data access layer that can use the benefits of each database and have all the data access go through that layer. Yes, you have to maintain all that code, but it really ends up benefitting the customer because you can use the power of whatever database you connect to.


>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.