Also a quick look at the dbeApplicationdData.vb will reveal all code needed to handle the XML file for things like the Server Settings for the Server Console application.

Thanks Trent

Edhy Rijo

Wow, I didn't know that. That's very cool.

Well, you can talk to these files the same way that we do.  In the UI assembly there are two BOs that talk directly to the applicationkeys.dat and connection.dat files.  They wrap the encryption, etc.  So you could just create an instance of each to manipulate these files. 

That's a very good point Alex! Deleting connection.dat file just wiped out StrataFrame connection info on my dev machine. So, I had to reentered it again on VS .NET startup

The connection strings don't get loaded into the connection store (connections.dat) when they are set directly via the DataLayer.DataSources.Add() method. They shouldn't need to as it sounds like the connection strings are known by the various assemblies.



Also, a little background. The ConnectionManager is really just a UI that allows the user to enter information that gets built into a connection string and then can store that connection string someplace (connections.dat) were it can be reused. The connections strings are stored by key, actually allowing multiple connections per type (so multiple apps can use the same file...so yes, deleting this file for one app would also delete the connections for other apps too, thus the user would have to reenter the connection info for those other apps). Check out ConnectionManager.ShowAvailableConnectionStrings().



The ConnectionManager then just uses the info to build the connection string and then add the data source using the exact same method you'd use to do it yourself (DataLayer.DataSources.Add()).



So, if your connection strings come from some place else, no need for ConnectionManager. It's job is to manage connection strings entered by the user...that's all. Here are some possible sources for the connection string:



- ConnectionManager prompts user for info, then uses the stored info next time the app opens.

- Connection string is set directly via DataSources.Add()

- Connection string is saved in a constant

- Connection string is retrieved via a property of a class

- Connection string is retrieved via a method of a class

- Connection string is retrieved form the App.Config file

- Connection string is retrieved from an XML file created using XmlBasics (SF tool)

- Connection string is retrieved from a Windows service, via TCP

- Connection string is retrieved from a web service

- etc.



In all cases, the connection string and a key are used to create the data source using DataLayer.DataSources.Add("key", "connection string").



I'm guessing that you would just use the connection manager to handle a limited number of connections and then get the other connection strings via method calls in the various assemblies.



You can allow the user to manage connections, by calling the ConnectionManager.ShowAvailableConnectionStrings(). They can add/remove connections as needed. I don't think there is a programmatic way to remove a connection though (and it would be hard, as the user actually can provide a name for the connection, which you wouldn't know).



Hope that helps!

Trent -



If the user is running multiple StrataFrame applications with different data sources this could be problematic, no?

________________
_____/ Regards,
____/ al

Yes, but from what I've seen (and I could've been doing something wrong) adding new datasource does not persist connection string to the connection store.

The simple answer is no, ConnectionManager requires user interaction. Once the information is collected, it is placed in an encrypted XML file (connections.dat). You might be able to pull this off...but you don't want to, there is a better way that isn't hard.



For those connections that are not user configurable, just setup the datasources directly, via code:







You'd add a data source for every one you need. Likely, you'd reference the appropriate method in the assembly to get its connection string. The "key" is then set on the BO so it knows were to get the data.



That make sense?

Hi Trent, Thanks for Replying,



Could you comment on the second part:







Thanks

This will work fine.  They should already have permissions to this folder location anyway, so this should not be an issue.