There are two ways to manage your connection(s):

- using the ConnectionManager. This is the dialog you see (sometimes) when you open the app that prompts you for the connection information. This results in a data source(s) being set.

- directly setting the data sources. In this case you manually setup the data source, including the key used by the BOs to reference the appropriate data source.



So, this line is used to tell the ConnectionManager that you need the connection information for a data source. The ConnectionManager then uses this to either prompt the user for the connection information (via the dialog) or it uses the last connection set by the user (it saves the connection information on disk in an encrypted xml file).



The first parameters, "", is the key used to access this data source. This is the default key for BOs (set with the DataSourceKey property of individual BOs). The second is a name used within the connection manager to identify the connection (you can have any number of connections...though I don't recommend that when just learning!). The third identifies the type of data source. SF has SQL, Oracle, FoxPro, Access and I believe Db2 data sources (there is also an enterprise datasource, but that has to be done manually). If you need others you can actually create them (again, not in the beginning ). The next is a description describing the data source, so the user is clear on what connection they are entering. The ConnectionManager really just facilitates creating the connection string to the data source, so the DataSource can be added, as if you had done it manually via....



The DataLayer.DataSources collection is the collection of defined data sources that is available to the application. You can define a data source manually using a line like this one.



DataLayer.DataSources is a collection of data source items. The data sources are the code that will actually interact with the data source, usually a database, but it can be other types as well (with a bit of coding). You add data source items (of the types mentioned above) to the collection. Each data source item has a key and a connection string. The key is the same as you'd enter using the ConnectionManager for the first parameter. The connection string is an ADO.NET connection string that is used to connect to the data source.



Now for the important part...you only do one or the other, but not both for a connection. I.e. you either use the ConnectionManager to setup a datasource XOR you use the DataLayer.DataSources collection. (OK, you could use both, but for the love of warm pajamas on cold nights, don't even think about it). You can mix them if you are setting up multiple connections, but I'd keep it simple at first...one connection, use one technic (of course you can experiment with the two types, switch back and forth...just comment out the other one so only one is active at a time).



Now, when you create a SF project, the SetDataConnections event handler will actually be all setup to connect to a data source, via the ConnectionManager. If you touch nothing, when you hit F5, it will prompt you for the connection info. This is very handy when doing sample/learning projects. You just start creating BOs and whatever else you want, then when you run it, simply point to the database you build the BOs off of. The StrataFrameSample db is excellent for this sort of work.



You will also note that commented out is a section for creating manual data sources. There are examples of several different type of data sources. If you decide to try one of these, just comment out the ConnectionManager code above it.



Hope this explanation starts to clear up your confusion!

Thanks, Greg...things are getting a bit clearer.  For DB development, I will have two database connections.  The first is handled via the ConnectionManager and is for the StrataFrame database used in development only.  There is always only one of these.  The second database connection for my application data is handled in several ways, but always associated with the run-time environment.  I can set it via the connection wizard on startup or through several options in the startup code.  I can have as many of these database connections as necessary.  Do I have it?

Your getting closer



The connection to the StrataFrame db is used only at design time and only by the tools within VS, such as the BO Mapper, the security dialog, the localization dialog and by the SF addin within VS. Thus you never need to set that connection within the application itself. You set that connection on the SF menu within VS. The connection to the SF database is only needed on the development machine, never on any machine running your app.



Within the application, you setup any connections you need (as many as needed...I'm using two, one for security and one for the app data, I believe I remember seeing posts of users using many connections, one db for each region supported by the db and the connections can be to different kinds of databases, I.e. you could connect to a SQL Server, Oracle and Access all in the same app). For each connection you have (roughly) two choices: use the connection manager or set the connection manually using the DataLayer.DataSources() collection directly. The difference is that if you use the connection manager, the user needs to know how to log onto the database. This could be fine in many circumstances and not fine in many others. If you use the DataLayer.DataSources() collection, the connection information can be set automatically and the user need not know anything about the connection or the database. Again, there are times when this is needed and times when it isn't.



For your initial learning, I'd skip this part, just use the connection manager (which is the code that is enabled within SetDataSources in AppMain when a SF project is used) and work through some of the other stuff first. Get a bit more comfortable with how BOs work, with data binding and with some of the SF controls. Then come back to this. Keep the questions coming too...it really helps as you work through each of these concepts.

That's a pretty darn good explanation, Greg; you're on top of it.  Thanks.

Any time. I'm glad I'm starting to get a clue after...oh...8,000,000,000 posts asking questions just like this

Hi,



I have also found it quite beneficial to code my application so that little or no changes are required to the code between development and production, for web applications my applications detects the domain space the app is using (localhost versus www.something) ** thanks again Trent for this idea ** and pulls the appropriate connection string from a shared class. I do something similar for desktops. I used to have to replace connection strings before compilation for production and naturally missed a few along the way, now I just write it up from to be aware of its surroundings and forget about it. The only time I have to change that logic is if a server changes frequently, which is not the case for me in most applications. In the one instance that was a consideration I still wrote the class, I just pulled the encrypted strings from an XML file.



Also two lines of code can plug the connection manager functionality into you application when an admin user might have to change the connection string.



Good luck.

Keith Chisarik

G'day

This is a very informative discussion. I have a couple of questions to ask.

We have been developing our application with the intent of adding security later on, so we have not delved too deeply yet, but the time is fast approaching. There has been mention here of seperate connections for Application Data and Security, I've also seen in the documentation that setting the SecurityDataSourceKey is not required if the SFS* tables are in database specified by the default DataSource. It there a best way of handling the Security tables, or is it a case of using whatever approach is applicable to the situation at hand?

Our application is a factory production system, used by workers many of whom have never touched a computer before. The system runs as terminal server sessions on a dedicated application server, with the data residing on a dedicated dataserver. We currently use .udf files to set the database connection, when we install the system, and this is only changed when due to server failure we need to host the database on the application server as well, and after repair to set it back again. This is a process that is only done by us or under our direction.

The application will only ever be run on the application server and the data can only be on the dataserver or the application server. We don't want to hard code the connection data, but as importantly we NEVER want our users to be asked anything about a database connection. When (not if) dataserver fails we need a means to quickly swap the datasource to Appserver and get going again (there could be 50 or more workers standing around twidling thumbs at this stage).  Any thoughts on the best way to handle this?

We though we would be able to write a program that would use the Connection Wizard (or something similar) to set the connection strings for the system (presumably stored in "C:\Documents and Settings\All Users\Application Data\MicroFour\ConnectionData"), that the other programs would use. Will this work or will we have to use the DataLayer.DataSources() collection and find some other place to store the connection data?

Peter

I split mine up because the db I'm converting uses Triggers extensively, and the DDT doesn't support them...and deploying the security tables/views is sooooooo easy with DDT it just made sense. Also, the next major version of SF is rumored to possibly have some significant enhancements to the RBS module that will require SQL Server 2005 to work. By splitting them I can easily convert the security db and not have to with my app db (on SQL Server 2000). Other reasons to split them might be for performance (put security on a separate server), or security reasons. I.e. it totally depends on the situations at hand!







You might want to check out shared settings files in SF help, as another option to manage connection information.

All of Greg's comments are very good.  I thought I might add a few things that we do with our medical application as well.

We actually use a single database and include the SFS tables in that same database.  This just makes distribution easier in the long-haul for us.  But splitting these up is totally viable as well.  It really comes down to what would suit your needs best.

On our medical application we got kindof fancy so that none of the client workstations would ever have to ask for a connection...it finds the server by itself.  When the server installation takes place we DO ask for a connection through the installer.  This only has to be done once and when an upgrade occurs in the next update, this information is remembered so that they do not have to enter it again.  We have a service that runs on the server that manages our licensing, amongst many other things, including handing out connections to the clients.  When a client workstation starts and the doesn't know the connection information or the connection fails, it sends out a UDP broadcast to the network which the server "hears" and in turn sends out a UDP broadcast back to the client with the information that directs it to the server.  Once it finds the server, it will authenticate and the server will send the connection information back to the workstation.  All of this without the end-user ever having to know or do anything.  It has really made a difference in support....this is no longer a support issue....now we are one to other problems   If the connection needs to change, then we go to the server, open up the connection dialog (we have a UI interface on the server), change the connection string, then restart the service (all automated).  This may be more involved than what you are looking to do...but it may give you another idea.

Greg & Trent,

I suspect that for simplicity we will also include the security tables in the Application Database. Although we also use triggers we don't use DDT, and we are developing for SQL Server 2005 so we don't have your constraints Greg.

It sounds as though there are any number of means of setting connections, so when we get to it we can choose the most appropriate.

Thanks for the advice.

Peter