Hi Doug,

Each user has their own copy of the DBC so my intentions were to have the system automatically update the various DBC's whenever a server name changed (which is pretty rare but does happen).

Thanks for the advice and tips Doug ... I will take sure suggestion and look into opening and closing the tables thru code rather than using the AutoOpen property.

BTW ... thanks for all of the great articles through the years!

Robert

>Hi Robert.

>It's possible to hack the PROPERTY memo in a DBC; I can post the code here if you really need it. However, I'd caution against it. First, in my experience, hacking the DBC seems to make it more fragile over time. Second, if this is a multi-user application, changes for one user will affect all users (which may not be a problem for you).

>I think it's better to turn off the AutoOpenTables property of the DataEnvironment and manually open the tables yourself, specifying the CONNSTRING for the views. Yes, having VFP do something automatically is nice, but you get more control if you do it yourself. That way, you can store the connection string in your own table, INI file, etc. and encrypt it if desired so prying eyes can't read it (which they can do with the DBC using even Notepad since the connection information is stored in plain text).

>Doug

>>In the past, I've created DSN connections and created a reference to the DSN in the "connections" section of the Project/Database. However, I have recently started using "connection strings" instead of a DSN stored on the local computer. I have figured out that the connection string info gets saved in the DBC. I have been able to locate the string info in the "Property" memo field, if I USE the DBC. However, I see that the data is compiled in some way and is not just plain text.
>>
>>I would like to put the connection string info in a table and have the application check for changes in the .DBF to see if anything has changed from what is stored in the "Property" memo field and, if it has, update the "propery" field. My question is this: Am I going to run into problems if I try change (udate) this compliled data programically in the DBC. Any "hints" or "gotchas" on how to do this?

>> Robert