Sure

Thanks Trent.

Yes.

The only registry entries that are created are the ones that you define.  For example, if you set the RegistryRepositoryKey property on a form, this key will be used to save the forms settings.  So you are in control of this.

Okay, we do not use the connection wizard to manage connections so the ConnectionData.dat won't be a problem. 

I do use getActiveLanguage, but at this point we only support 1033 until we have time to do the translations, so if I hard code the language = 1033 will this stop the access to AppLanguage.dat?

What about registry entries, other than domain, which I can move to the database, do you guys write any other registry entries?

Thanks

Tim

You have one of two options.  First, you can allow access to the C:\Documents and Settings\All Users\Application Data\MicroFour folder.  Depending upon how you are managed your connection strings the ConnectionData folder may not even be used.  This folder is only used when using the automated Connection Wizard when the SetConnections() method is called in the AppMain.vb file (SetDataSources() method).  The LocalizationDataFolder may not even be necessary if your application does not support multiple languages.  This is set in the InitApplication() method of the AppMain.vb by calling the GetActiveLanguage() when setting the LocaleId.  You can just manually set the MessageLocaleID = 1033 to support English for example. 

The second option basics would rely on you creating some other logic to pull your localization and connection string information from some source on which you do have access.  For example, in our medical software we pull our connection strings from a server service that sends the connection string info through a UDP connection.  So the local files are never touched.  Then once a user logs in and I have access to a database, we pull their preferred language from a preferences table, so again the local folder is not touched.

I am running into workstation permission problems on AppLanguage.dat and ConnectionData.dat (see Attached) and I'm wondering if you have any suggestions on how to solve.  We have many companies locking down their environments. When we install our SF application in the locked down environments we are getting permission errors on AppLanguage.dat and ConnectionData.dat, and  the registry as well, with 'Standard Users'. Users with Admin permissions are fine.

Do you have any suggestions on how to solve this problem?

Thanks,

Tim