Hi Kevin;

Although it is possible to modify data in the DBC the way you suggest, I don't know if that is a reasonable solution. (VFP gives us so many ways to accomplish our tasks!)

In most cases I think, remote views are all defined using a single defined connection. This makes sense because you set the views to share connection which means you only have one connection to the remote database.

The problem occurs when you want to connect to a different remote database or even when you deploy a system, including database, to users who may have defined their ODBC DSN's with different names than you used for development.

Again, it is very simple to change the Connections defined properties which ultimately affects all of the remote views defined with that connection. These DBC based connections are unique to VFP (ADO and VB doesn't have them).

At login time, the user can then select the database they wish to use (production, test, etc.) and the Connection can be modified to point to that location. When the views are opened, they can point to selected database.

The only weakness I have with this system is the fact that the login password for the user to the database is stored in the DBC unencrypted. Someone with access to the DBC with a tool that can read a DBF can easily find the login password and userid.

However, I have yet to see a system that doesn't have hard-coded access in a file, table, registry entry or ASP page.


>>>So the question is: is there a way to alter the connectname for a remote view without deleting and recreating it? (we have a good number of remote views). We would also like to avoid just changing the database in the ODBC source (by going to ODBC admin) since there is the chance of forgetting to change it back as we switch environments.<<
>
>
>Actually Bob Lucas's approach looks good. But another idea would be to
>a) open "Your.dbc" just like you would a DBF
>b) Look for the objecttype="Connection" and then change Objectname to the desired connection name.
>
>OK -- I have never tried this, but unless the properties field carries a reference to the connection name, it should work fine (please back up your DBC before trying).
>
>Kevin