TableAdaptors: Why a good solution?

  • Thread starter Thread starter Claus Konrad
  • Start date Start date
C

Claus Konrad

Being an old rat in this game, I've come to discover some "unpleasent" features of the newer version of .NET (2.0).

The tableadaptors contains an embedded connectionstring that is only available through global connectionstorage!

I see the benefit in being able to encrypt the connectionstorage, I do however NOT see the benefit in the notion of "global" connectionstrings. Why would I want to "share" my own connectionstring with every other application installed on my PC? Being global - I assume that it is available to every body by using the .....ConfigurationManager.ConnectionStrings["some name"].ConnectionString construct?


Kind Rgds
/Claus Konrad
 
m8,
I'm spending hours trying to understand how to by-pass this config file.
All I want is to centerlize all the connection's of the table adapters to an
connection object (like it used to be) instead of this "configuration file".

got any ideas ?
 
Unfortunately - the only way I see right away, is to expose the internal Connection object through a propery of the adaptor class generated from VS.NET 2005.
This should be exposed as a propery on the tableadaptor class to allow you to set if from "outside" (e.g. business object).

But - some means of logic or reasoning must exist behind this architecure change from the great "mothership" (MS)?



<code type="existing default code">
[System.Diagnostics.DebuggerNonUserCodeAttribute()]

internal System.Data.SqlClient.SqlConnection Connection {

get {

if ((this._connection == null)) {

this.InitConnection();

}

return this._connection;

}

</code>

Dror said:
m8,
I'm spending hours trying to understand how to by-pass this config file.
All I want is to centerlize all the connection's of the table adapters to an
connection object (like it used to be) instead of this "configuration file".

got any ideas ?

Claus Konrad said:
Being an old rat in this game, I've come to discover some "unpleasent" features of the newer version of .NET (2.0).

The tableadaptors contains an embedded connectionstring that is only available through global connectionstorage!

I see the benefit in being able to encrypt the connectionstorage, I do however NOT see the benefit in the notion of "global" connectionstrings. Why would I want to "share" my own connectionstring with every other application installed on my PC? Being global - I assume that it is available to every body by using the ......ConfigurationManager.ConnectionStrings["some name"].ConnectionString construct?


Kind Rgds
/Claus Konrad
Click to expand...
Click to expand...
 
....and you see an example here on how to extend the tableadaptor.
Instead of overriding the ToString() method, add a property exposing the
ConnectionObject in the same manner as the example.
http://msdn2.microsoft.com/en-us/library/ms233697.aspx

/Claus

Dror said:
m8,
I'm spending hours trying to understand how to by-pass this config file.
All I want is to centerlize all the connection's of the table adapters to
an
connection object (like it used to be) instead of this "configuration
file".

got any ideas ?

Claus Konrad said:
Being an old rat in this game, I've come to discover some "unpleasent"
features of the newer version of .NET (2.0).

The tableadaptors contains an embedded connectionstring that is only
available through global connectionstorage!

I see the benefit in being able to encrypt the connectionstorage, I do
however NOT see the benefit in the notion of "global" connectionstrings.
Why would I want to "share" my own connectionstring with every other
application installed on my PC? Being global - I assume that it is
available to every body by using the
.....ConfigurationManager.ConnectionStrings["some name"].ConnectionString
construct?


Kind Rgds
/Claus Konrad
Click to expand...
Click to expand...
 
Back
Top