We Keep Coding

Do I have to define the connection info in the Ibconfig file for Ideablade Devforce Classic 3.8.5?

We are using Ideablade Devforce Classic 3.8.5.
I would like to use a separate file (not ibconfig) to define all connection strings, and then read those strings and set Ideablade to use them when connecting to the DB.
The connection strings may be for Oracle/SQL Server/Access.
Can I dynamically build and use these separate connection strings on startup of my app? Or do I always need to have them defined in ibconfig? Thanks.

DevForce will look for connection strings (rdbKeys) in a config file - either a .ibconfig or app.config file - and via an implementation of the IDataSourceKeyResolver. The resolver allows you to resolve connection strings at runtime, so is probably what you're looking for. You can find more information on how to use it both in the Developers Guide, and in a Learning Unit called "Custom DataSourceKeyResolver" under the "300 Advanced" folder. Learning units are optionally installed with the product.

Override default connection string

In an MVC web application I want to override connection strings based on the development machine I'm using. I can use Web.config transformations, but I also need to override connection strings in various non-web config files. I can use the SlowCheetah extension, but then I will end up creating the same transformation for every project that accesses the database. This is a hassle to maintain when the project becomes bigger and has more developers.
What I would like to do is modify the way Entity Framework or ASP.NET look for connection strings, adding a class of my own that looks for connection strings, and only implement the transformation logic once. I would hopefully use Ninject to inject it only when relevant.
Is there such an "IConnectionStringProvider" interface I can implement and register, and automagically have ASP.NET and EF use it?
EDIT. I have found this, but it seems real nasty. If there's no cleaner way, I'll just use multiple identical configuration translations, and maybe let the source control system duplicate them properly.

You can tell Entity Framework to use a different connection string - it doesn't have to use the default one in web.config.
Here is an example: http://www.codeproject.com/Tips/234677/Set-the-connection-string-for-Entity-Framework-at
Here is another: http://msdn.microsoft.com/en-us/library/bb738533.aspx
It's up to you how you architect the rest of it.
Personally I use an app setting in web.config to tell my code which connection string to use for a particular part of the system, e.g.
var connectionStringNameForMyFeature = ConfigurationManager.AppSettings["connectionStringNameForMyFeature"];
myFeature.ConnectionString = ConfigurationManager.ConnectionStrings[connectionStringName];

Inject connectionstring from app.config vs read it from a BaseDataProvider class

Do you see any benefit in injecting the database connnection string from the Global.asax.cs
class in ASP.NET MVC compared to the method in reading the connection string from a BaseDataProvider class accessing the app.config file?

I'd prefer to inject any objects needed using constructor injection (whenever possible).
One small advantage I see is transparency regarding a class's dependencies.
For example, if you try to instantiate a class in a test harness (while doing integration testing):
in the first case (constructor injection) you immediately see that it needs a connection string and provide one
in the second case you instantiate the class (perhaps using a default constructor) and after some trial & error discover that it depends on the ConnectionString property being set
Update:
Another advantage of the constructor injection approach is that it decouples the class itself from the mechanism of getting the connection string from the app.config.
This could enable in the future scenarios that you don't even think about right now.
For example, in a project I currently work on I have a component that has db access and I have reused it in several contexts. In some of them it uses a standard connection string coming from the config file, while in others I have another component that decides which connection string to use based on some conditions.
If you go for the second approach, you'll need to change the code in order to support such a functionality.

I usually take a hybrid approach such that my BaseDataProvider class has an empty constructor which defaults to whatever is stored in the config, but is overriden to accept a connString for cases where I need a connection other than the default.
Then my Global.asax class contains the necessary logic to determine what connection string they might need in a given situation. For example, say you have your web application deployed internationally on servers all over the world, you'd want to connect to the nearest available db server to avoid latency issues. So on user login, I would figure out where my user was and then set them up with the appropriate connection

How Do I Manage Data Connection From Within A Class Library in a Solution With Both Website and Form Apps?

This is a common problem for me. I have a solution that contains a Form App or two, a couple of websites(Intranet, External site kinda thing) and a class library where I want to store my data objects to be shared among the other project mentioned.
Normally, I'd have my connection strings stored in web.config and app.config files. However, with the class library, this isn't really possible. Not without passing in configuration information each time I want to access data. I'd prefer not to do that.
What's the best way to solve this problem?

If you put your connection strings in the web.config and the app.config of the referencing applications the Dll's will read them fine. If you want them shared you can put them in a machine config. You could also put them in a separate file and reference them from each web and app config.

Can I create a Database connection in a Class Library Project?

I am setting up a .net project that is called to generate other webpages. Basically a true CODE BEHIND page. How do I go about making a connection on a Class Library File, when there is no webconfig file present/available?

In this case, I would create a 'Base Page' that derives from System.Web.UI.Page. On this page, you would create a property called 'ConnectionString'. You will have all of your web pages you create inherit from this page.
Example:
public partial class BasePage : System.Web.UI.Page
{
protected string ConnectionString
{
get
{
return System.Configuration.ConfigurationSettings.AppSettings["MyConnectionString"];
}
}
}
And in your web.config
<appSettings>
<!-- Connection String -->
<add key="MyConnectionString" value="Data Source=myServerAddress;Initial Catalog=myDataBase;User Id=myUsername;Password=myPassword;"/>
</appSettings>
Now you can have a web.config file with a connection string that is easily readable. And you can store this 'Base Page' in your class library, no problem. As long as your web pages inheriting from it are using the web.config file with the connection string.
After that, it's a simple matter of connecting using that string. You can do this in a variety of ways, either in your web pages, or in separate classes (I recommend separate classes). In this case, if you had a separate class, you would need to pass in the ConnectionString property to your connecting functions:
public void ExecuteQuery(string connectionString, string sql)
{
using (System.Data.SqlClient.SqlConnection theConnection = new System.Data.SqlClient.SqlConnection(connectionString))
using (System.Data.SqlClient.SqlCommand theCommand = new System.Data.SqlClient.SqlCommand(sql, theConnection))
{
theConnection.Open();
theCommand.CommandType = CommandType.Text;
theCommand.ExecuteNonQuery();
}
}
or you can create a function that does not take a connection string parameter, and just reads from the web.config file. It sounds like you may want to put your connecting and data access code in a class library for good separation of data and content. Hope this helps!

There are several ways to solve this:
1) If you're class library is really going to generate web pages, then it will probably be deployed on the server with the web.config and so can use properties of the web.config file. If you don't want to use the ConnectionString part, then you can just make an appSetting with the connection string.
The benefits of doing this are that it's easy to change or have different connection strings for different environments (testing, deployment, etc.). And if you decide to use the class library in another kind of app, you can use the app.config file with the same setting.
Depending on the type of database, you'll be using the System.Data and possibly some of the sub-namespaces to make this work.
2) You can hard code the connection string into the code. Ugly, but workable in a pinch.
3) You could use an entity framework to help you out and cut down on the work that you have to do.

System.Data namespace. If using SQL Server, a SQLConnection object.
I use the Application Data Blocks for data access b/c I think it is a time saver. That framework is great for SQL Server access.

Will your library be called from an ASP.net site? If so, you can still use the same methods for accessing the application settings. Otherwise, you may need some kind of app.config for whatever front end you're putting on this.

Also, you don't need a connecting in your configuration in most class libraries, unless you are using an ORM which needs to use it to pick up some info. The calling application's configuration will be used when you are running the thing, so it will pick up the configuration out of the web.config or whatever.