After installation, I was able to successfully create a business object and map it to a table on my remote database.  A new form was created, the business object attached and some fields slapped on for testing.  No errors upon the build; however, if I run the debugger, the application fails nearly immediately with some such statement that my DataLayer is out of whack.  If I goof around with the program.cs file, I can get a database connection popup to occur when I start the app...it is looking for the "missing" connection information:  server name, authentication, database name.  If I provide all of that, then I get an unathentication error.  What am I doing wrong?  I am going through the tutorial, but any kind of hint would be helpful on this...thanks!

Bill

Blow it away?!   After all that non-work that I did?!!? 

No prob.  I will try that out.  I guess I can add the security later (after I figure out the important stuff).

Thanks,
Bill

Does the BO database(s) have to reside on the same server as the StrataFrame (design-time) database?

No.  The two are unrelated.  If you are referring to the database to which your BOs will communicate, this database can reside wherever you may need it.  The StrataFrame database is only for design-time and has no effect on the run-time stuff.

This line seems important to the accessibility of the data for the business object:

ConnectionManager.AddRequiredDataSourceItem("", "SQL Connection", DataSourceTypeOptions.SqlServer, "MyDatabase", "This connection is used by AspireSF.");

Even if I changed the "MyDatabase" to the proper name, how does this RequiredDataSourceItem know where the server is?

In addition, how does the following line play into all of this:

DataLayer.DataSources.Add(new SqlDataSourceItem("", "myconnectionstring"));

Sorry for my confusion on this...I have messed around with these settings, but have not found a successful combination, yet.

Thanks!
Bill

 

I copied the connection string from my Business Object Mapper project properties window into the DataLayer.DataSources.Add method.  It seems to be working at the moment...but, I am not sure why.  The customersBO1 object on the form has an empty string in the DataSourceKey field.  Also, I had no dialog this time asking me to connect to the SQL Server.  Somehow, this change made a difference.  For the time being, it is a mystery to me.

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