Ivan:

>Is it possible to have only one project giving me this
>option ? I mean, not having one to work locally and another version for
>remote.

This is really a design issue. If you design your application carefully, there is no reason why a single package cannot provide local or remote data support. Rather than the project being the main issue, other factors like DBC's are perhaps more the area of focus. The view definitions could be kept in separate DBC's with internal application logic that uses the same aliased views from either the "local" DBC container or the "remote" DBC container dependent on the customer's requirement. Also, in the CDE, you could put custom logic in, say, the BeforeOpenAll() hook event that could loop around your cursor objects and modify the cDataBase and cSource properties to fix-up the appropriate values to point to the correct database/source viewname(s) (whilst maintaining the same cWorkarea value) dependent on the data source required by the application instance.

In my applications, I tend to use the the old Codebook approach of naming local view lv_ViewName, remote view rv_ViewName and alias them as v_ViewName. My code always refers to the alias v_ViewName but the actual prefix values indicate whether the source view is local or remote. This will allow you to keep the view definitions in the same DBC, if you like. Codebook actually allowed you to change the view source "on the fly" using this naming convention. If you keep the view names the same but with different definitions based on local or remote, then you would keep them in separate databases.

As I said, there are numerous ways to achieve what you require, some more obvious than others depending on your overall system design.

HTH