More control over ConnectionManager


Author
Message
Leonard P.
Leonard P.
StrataFrame Novice (93 reputation)StrataFrame Novice (93 reputation)StrataFrame Novice (93 reputation)StrataFrame Novice (93 reputation)StrataFrame Novice (93 reputation)StrataFrame Novice (93 reputation)StrataFrame Novice (93 reputation)StrataFrame Novice (93 reputation)StrataFrame Novice (93 reputation)
Group: Awaiting Activation
Posts: 65, Visits: 306
Hi,

I have a few questions regarding connection manager.

First I need to be able to "purge" all connections stored on user machine in Connections.dat.

This is what I came up with so far:





private static void PurgeConnections()

{

try

{

string connectionDat = Path.Combine(ConnectionManager.ConnectionDataFolder, "Connections.dat");

File.Delete(connectionDat);

}

catch

{ }



}





Does this make sense?, or is there something within SF that I could use? Also my concern is when this code runs on the machine where loged user is not in admin or power user roles. Would this code work?



Second, is there a way to write a new connection string to Connection.bat without calling .SetConnection or .ShowAvailableConnectionsWizard (i.e. without user interaction), my FS application reference other assemblies that manager their own connection strings, and I wont to be able to store them in ConnectionManager.



Thanks

Reply
Greg McGuffey
Greg McGuffey
Strategic Support Team Member (4.8K reputation)
Group: Forum Members
Posts: 2K, Visits: 6.6K
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! BigGrin
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Threaded View
Threaded View
Leonard P. - 16 Years Ago
Trent L. Taylor - 16 Years Ago
Leonard P. - 16 Years Ago
Greg McGuffey - 16 Years Ago
Leonard P. - 16 Years Ago
Alex Luyando - 16 Years Ago
Greg McGuffey - 16 Years Ago
Leonard P. - 16 Years Ago
Trent L. Taylor - 16 Years Ago
                         Wow, I didn't know that. That's very cool. :D
Greg McGuffey - 16 Years Ago
                             [quote][b]Greg McGuffey (03/06/2009)[/b][hr]Wow, I didn't know that....
Edhy Rijo - 16 Years Ago

Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search