StrataFrame Forum

Only a single store for Database Connection Wizard data???

http://forum.strataframe.net/Topic27734.aspx

By Sam Tenney - 7/26/2010

I am still a beginner and so I am not sure if the problem I am seeing was caused by something I did wrong or if my complaint is valid, but here is what I am seeing.

While learning StrataFrame I create lots of little applications to test various things.  These applications access lots of different test databases and tables.  Today I made a mistake when I first launched a new test application.  I mistakenly chose the wrong database and table when the Database Connection Wizard ran.  Les Pinter's article showed me how to delete the Connections.dat file and the AppKeys.dat file to force the Database Connection Wizard to run again.  That did cause the wizard to run again, but I was surprised that now the wizard must be run for every test application that I have previously created and for which I have already completed the wizard.

To my surprise I discovered there is only one pair of Connections.dat and AppKeys.dat files that are used by all the applications I have ever run.  And I was surprised to find those files under the Documents and Settings\All Users\... folder on my Windows XP system rather than under my personal documents folder.

Did I do something wrong?  Shouldn't these files relate to only one application?

Sam Tenney

By Keith Chisarik - 7/26/2010

No, you have it right.
By Edhy Rijo - 7/26/2010

Hi Sam,



A trick I have used for this scenario is to just temporarily rename the ConnectionManager.Applicationkey value for one of your connections in the SetDatasource() of the AppMain.vb to force the Connection Wizard to show up.



Also you can create another application with an option to show you the connection wizard like this:



'-- Show the connection dialog and allow a connection to be selected

If MicroFour.StrataFrame.Data.ConnectionManager.ShowAvailableConnectionStrings() Then

'-- Since a connection was selected, then all of the existing dialogs need to be closed

' since their connection is established to the original source.

For Each loForm As Form In Me.MdiChildren

loForm.Close()

loForm.Dispose()

Next



'-- Force the connections to be reset

MicroFour.StrataFrame.Data.ConnectionManager.SetConnections()



End If
By Greg McGuffey - 7/27/2010

Sam, you are understanding it correctly. Edhy has some great ideas on how to deal with a situation like you had. The idea behind the ConnectionManager is to provide a simple way to manage connection information for SF apps that will be used by power users/developers. I.e. users who know how to connect to the database. In most business apps, this is typically a bad idea and the users have no information about the databases they are hitting. In this case you would use the manual way to setup the DataSources and manage your connections strings yourself. If you have more questions about this feel free to keep asking!
By Greg McGuffey - 7/27/2010

After posting my first answer, I started to ponder the issue some more. SF tends to build things so you aren't so pigeon holed into a specific implementation, so I did some more research into how the ConnectionManager works and it turns out there are some other, more elegant solutions.



First, there is a static (shared) property of the ConnectionManager that allows you to change the folder were the data files are stored. They don't have to be stored in the default location. You can have a set of files for each app if you wish. For test apps you might want to just put the data files right in the app folder. You'd add this before calling SetConnections:



VB

ConnectionManager.ConnectionDataFolder = Application.StartupPath()




C#

ConnectionManager.ConnectionDataFolder = Application.StartupPath;




Now, the AppKeys.dat and Connections.dat will be just for that app in the same folder as the executable (/bin/Debug typically).



A second alternative (for test apps) is to share an application key between apps (not to be confused with the SF shared settings). To understand this approach, I'll explain how I might use this.



I have a folder I use for all my test apps (the ones I want to keep anyway), E:\Research. Under this folder I then have folders for the samples. E.g. I have a AppSessionTest folder that contains a solution where I tested how the application session handling works in SF. I tend to use the StrataFrameSample database for most of these apps if they need data. For any app that needs to use the SF sample db, I could add the following to my SetDataSources() method:



//-- Use common connection data folder for research projects.

ConnectionManager.ConnectionDataFolder = @"E:\Research\ConnectionData";



//-- Use the common app key for the SF sample db.

ConnectionManager.ApplicationKey = "StrataFrameSampleData";




Once I've run one app that sets up the connection to my StrataFrameSample database using this App key and using the datafiles under my ConnectionData folder, all others won't need to prompt me at all. Kind of cool.



Note that I'd likely only use this with projects that only used just the sample db. If the solution was using multiple, I'd use a unique app key and maybe put the connection data in the app folder.



I hope this helps ease some of the pain you've had to experience. I know it will help me in a bunch of situations. Thanks for asking the question!