Develop Reference

how can i set the context_info sql statement from Devforce IdeaBlade app

I need to set the Context_info from my winforms application so that i can notify the database not to run a trigger if my application is saving a record vs a legacy app which needs to run the trigger. Everything i have read says it needs to be set using a data context.
In my application i am using an entity manager. How can i set the data context using an entity manager instead of a datacontext. I just want the trigger to know that it is my app running and saving the data on which the trigger is set
i want to do like the follow. "set context_info '0x1234'
at the start of the trigger i check to see if the context_info is set and dont run the trigger. The legacy does not set the context_info.

We needed to do this same thing for our app. As Kim mentioned, there is a lot of information in the Dev Force forums. You can find a full explanation of what we did in this forum post but I'll reproduce the important parts here for reference...
We had a similar requirement in our application. In our case, we needed to call a custom stored procedure every time a DB connection was opened - the procedure would 'mark' the connection with what user was currently active because we have lots of triggers that need to know the current user (we use context_info to accomplish this 'marking').
We were able to handle this with the help of the EF Provider Wrapper Toolkit (also seems to be on Nuget now). That basically lets you inject your own logic into various ADO.NET objects - so at the very lowest level of database access. We then made our own custom DbConnection class that DevForce/EntityFramework end up using. It was actually pretty easy and has given us a lot of nice 'hooks' into the lowest level of database access that has come in handy a lot.
Here is some sample code for our custom DbConnection class that shows the kinds of things you can accomplish:
/// <summary>
/// Custom implementation of a wrapper to <see cref="DbConnection"/>.
/// Allows custom behavior at the connection level.
/// </summary>
internal class CustomDbConnection : DbConnectionWrapper
{
/// <summary>
/// Opens a database connection with the settings specified by
/// the <see cref="P:System.Data.Common.DbConnection.ConnectionString"/>.
/// </summary>
public override void Open()
{
base.Open();
//After the connection has been opened, do our logic to prep the connection
SetContextInfo();
//...and we do some other stuff not relevant to this discussion
}
/// <summary>
/// Closes the connection to the database. This is the preferred method of closing any open connection.
/// </summary>
/// <exception cref="T:System.Data.Common.DbException">
/// The connection-level error that occurred while opening the connection.
/// </exception>
public override void Close()
{
//Before closing, we do some cleanup with the connection to make sure we leave it clean
// for the next person that might get it....
base.Close();
}
/// <summary>
/// Attempts to set context_info to the current connection if the user is
/// logged in to our application.
/// </summary>
private void SetContextInfo()
{
//See if a user is logged in
var user = Thread.CurrentPrincipal as OurCustomUserType;
//If not, we don't need to do anything - this is probably a very early call in the application
if (user == null)
return;
//Create the ADO.NET command that will call our stored procedure
var cmd = CreateCommand();
cmd.CommandType = CommandType.StoredProcedure;
cmd.CommandText = "p_prepare_connection_for_use";
//Set the parameters based on the currently logged in user
cmd.CreateParameter("as_session_id", user.SessionID, null, DbType.Guid);
cmd.CreateParameter("ai_user_sid", user.UserID, null, DbType.Int32);
//Run the SP
cmd.ExecuteNonQuery();
}
In EF6 and beyond, there might be a cleaner way to intercept database calls....but this approach has been working great for years.

Although the IdeaBlade forums have been closed to new activity, they are still searchable and do often contain helpful answers and information regarding DevForce issues. In this case, if you search for context_info there you will find some useful threads. One in particular shows how to use either the EF Provider Wrapper Toolkit or EF 6 DbCommandInterceptor to work with the context_info. These do not require a DbContext.

Why is the Destructor not being called?

I have a very interesting scenario where I would like a class to inform another entity it has been destroyed; however, its not doing what I want it too.
The Problem
The deconstructor, for some reason does not do what its supposed to do.
The Question
Why is the destructor not being invoked and make sure that it does do its necessary clean up.
The Code
So here we have the informer ~
class Connection
{
public const int Port = 50000;// Can be any range between 49152 and 65536
//Teh Constructor
public Boolean Connect()
{
//SetInformation
Information.Id = 545;
using (var WebServ = new ClientSDKSoapClient("ClientSDKSoap"))
{
ContinueConnection.WaitOne();
WebServ.ClientLogin(Information);
}
return true;
}
~Connection()
{
using (var WebServ = new ClientSDKSoapClient("ClientSDKSoap"))
{
WebServ.ClientLogout(Information);
}
}
}
Additional Information
I want the web service to record if the Connection Class is destroyed for any given reason.
When the client is connecting, it works perfectly. The Web Service records every method called from it. If I call ClientLogout explicitly, it will work.
I am aware I can implement IDisposable; however, this object is not intended to be used within the lifetime of one method. In fact, its intended for use for the entire duration of the program and the failure of this object basically results in the failure of the entire project. (Although I suppose main IS a method...)
I need to release a network connection; however, its not in this program, its in another program and unless ClientLogout is called, it won't be released.
My Research
Microsoft says that you should use the deconstructor for the release of unmanaged resources making an explicit reference to network connections. This ones got my quite stumped.

I think you should implement a Dispose pattern for your Connection class, rather than relying on an obscure deconstructor metaphor. This would be the "canonical" way to do it.
public class Connection : IDisposable // <== Inherit from IDisposable interface
{
public const int Port = 50000;// Can be any range between 49152 and 65536
private SomeType webserv; // Use whatever real type is appropriate here.
private Information information = new Information(); // or whatever
// This is a real constructor.
public Connection()
{
//SetInformation
information.Id = 545;
webServ = new ClientSDKSoapClient("ClientSDKSoap"))
webserv.ContinueConnection.WaitOne();
webServ.ClientLogin(information);
}
// Implement IDisposable interface
public void Dispose()
{
webServ.ClientLogout(information);
}
}
And then use it thusly
using (var connection = new Connection())
{
// Use the connection here.
}
The client will be logged out when you leave the using block.

Microsoft says that you should use the deconstructor for the release of unmanaged resources making an explicit reference to network connections. This ones got my quite stumped.
The docs here are misleading. It really just means you need a finalizer somewhere in your object inheritance chain, to ensure that any unmanaged resources are appropriately cleaned up. But you only need this finalizer once for the entire inheritance tree, at the level where the unmanaged resource is first allocated.
As an example, you do not need a destructor or finalizer if you build a class for a data access layer to wrap the SqlConnection type, because the core SqlConnection type already has one. What you should do, though, is implement IDisposable and write code to ensure prompt disposal, so the finalizer on your SqlConnection will be called sooner, rather than later. But if you were to build a whole new database engine that competes with Sql Server, MySql, Oracle, Access, and the like, and were implementing the ADO.Net provider for this new database engine, then would need to write a finalizer for your connection type, because none exists yet.
In this case, ClientSDKSoap type already has a destructor; you do not need to write another.

Disposing of SQL Connection

I have a SQL class that connects to the DB and retreives a DataTable. I am aware that the SqlConnection must be disposed when finished. I know this can be done using a using block, but is it also acceptable to put the Dispose() call inside the destructor of this class?
Herre is my code:
public class SQLEng
{
//Connection String Property
//Must be set to establish a connection to the database
public string ConnectionString{ get; set; }
SqlConnection _Conn;
//Overridden Constructor enforcing the Connection string to be set when created
public SQLEng(string connectionString)
{
ConnectionString = connectionString;
_Conn = new SqlConnection(connectionString);
}
//ensure the SqlConnection is disposed when destructing this object
public ~SQLEng()
{
_Conn.Dispose();
}
//various other methods to get datatables etc...
}
Basically i wish to have a class variable SqlConnection, rather than instantiate the SqlConnection inside every method that accesses the DB. Is this sound practise?

Your design encourages hanging on to a (presumably open) SqlConnection for long periods of time. Best practice is to open a connection just before you need it and then release (close and dispose) it as soon as you are finished.
Yes, there is some overhead associated with creating new connections; connection pooling alleviates much of that processing time. Worse is keeping many connections alive on the server.

Looking at the source for the Enterprise Library (from the MS Patterns & Practices team), the DAAB creates a connection as needed and disposes it as quickly as possible.
public virtual int ExecuteNonQuery(DbCommand command)
{
using (var wrapper = GetOpenConnection())
{
PrepareCommand(command, wrapper.Connection);
return DoExecuteNonQuery(command);
}
}
protected DatabaseConnectionWrapper GetOpenConnection()
{
DatabaseConnectionWrapper connection = TransactionScopeConnections.GetConnection(this);
return connection ?? GetWrappedConnection();
}
So I would say that is a best practice. In most cases, all you are doing is returning the connection to the connection pool, so really the connection is not closed per se.

If you wish to wrap the SQL Connection class, implement IDisposable and call the connection Dispose() from within your own Dispose() method. More info is here:
Properly disposing of a DbConnection
As to whether or not this is good practice - well, if all your doing is wrapped the SQL connection in another class, I'm not sure what you're achieving. All your methods will still need access to the instance of this class, in which case they could get access to the instance of the connection object by itself.

MySQL Connection using IDisposable C#

I am developing a MySQL Web App using ASP.net and I have heard that a using directive should be used for the mysql connection to ensure that the connection is always closed should something go wrong as their is no guarantee that the database will close from inside finally statement if a catch has occured (depending on the exception).
I am trying to create a class that opens the MySQL Connection so I haven't got to repeat the same code each time I need to access the database.
I have seen that it is something like
using (call class to open connection)
{
MySQL Stuff Here
}
I have seen that the class that is being called to open the connection needs to be an IDISOSABLe class but I am not sure how I can implement this.
However, I cannot find any information on how this can be done. Thanks for your help.

The typical way to implement the IDisposable interface is by following the pattern laid out in the example in the documentation: http://msdn.microsoft.com/en-us/library/system.idisposable.aspx
Basically, your class should/would look like this:
public sealed class YourClass : IDisposable
{
private MySqlConnection _Connection;
private bool _IsDisposed;
public YourClass()
{
_Connection = new MySqlConnection();
}
public void Dispose()
{
if (!_IsDisposed)
{
_Connection.Dispose(); // or Close
_IsDisposed = false;
}
}
}
There are numerous variants of this pattern, depending on whether you intend for others to inherit from your class, and whether you have any unmanaged resources you need to close (like file handles), but for normal use, the above is enough.

MSDN :)
http://msdn.microsoft.com/en-us/library/system.idisposable.dispose.aspx#Y800
However I'm not really sure what you are trying to achieve will be of any benefit to you. What is your wrapper class doing differently than just using the connection object
what data access design pattern are you using?

passing DB Connection object to methods

Was wondering if it is recomended to pass a database connection object around(to other modules) or let the method (in the other module) take care of setting it up. I am leaning toward letting the method set it up as to not have to check the state of the connection before using it, and just having the caller pass any needed data to the calling method that would be needed to setup the connection.

Personally I like to use tightly scoped connections; open them late, use them, and close them (in a "using" block, all within the local method). Connection pooling will deal with re-using the connection in most cases, so there is no real overhead in this approach.
The main advantage in passing connections used to be so that you could pass the transaction around; however, TransactionScope is a simpler way of sharing a transaction between methods.
Since the classes are implementation specific, I'd write each to open it's own native transaction. Otherwise, you can use the ado.net factory methods to create the appropriate type from the config file (the provider name).

Personally, I like storing a stack of my current open connection and transactions on top of the Thread Local Storage using SetData and GetData. I define a class that manages my connections to the database and allow it to use the dispose pattern. This saves me the need to pass connections and transactions around, which is something that I think clutters and complicates the code.
I would strongly recommend against leaving it up to the methods to open connections every time they need data. It will leads to a really bad situation where it is both hard to manage transactions throughout the application and too many connections are opened and closed (I know about connection pooling, it is still more expensive to look up a connection from the pool than it is to reuse an object)
So I end up having something along these lines (totally untested):
class DatabaseContext : IDisposable {
List<DatabaseContext> currentContexts;
SqlConnection connection;
bool first = false;
DatabaseContext (List<DatabaseContext> contexts)
{
currentContexts = contexts;
if (contexts.Count == 0)
{
connection = new SqlConnection(); // fill in info
connection.Open();
first = true;
}
else
{
connection = contexts.First().connection;
}
contexts.Add(this);
}
static List<DatabaseContext> DatabaseContexts {
get
{
var contexts = CallContext.GetData("contexts") as List<DatabaseContext>;
if (contexts == null)
{
contexts = new List<DatabaseContext>();
CallContext.SetData("contexts", contexts);
}
return contexts;
}
}
public static DatabaseContext GetOpenConnection()
{
return new DatabaseContext(DatabaseContexts);
}
public SqlCommand CreateCommand(string sql)
{
var cmd = new SqlCommand(sql);
cmd.Connection = connection;
return cmd;
}
public void Dispose()
{
if (first)
{
connection.Close();
}
currentContexts.Remove(this);
}
}
void Test()
{
// connection is opened here
using (var ctx = DatabaseContext.GetOpenConnection())
{
using (var cmd = ctx.CreateCommand("select 1"))
{
cmd.ExecuteNonQuery();
}
Test2();
}
// closed after dispose
}
void Test2()
{
// reuse existing connection
using (var ctx = DatabaseContext.GetOpenConnection())
{
using (var cmd = ctx.CreateCommand("select 2"))
{
cmd.ExecuteNonQuery();
}
}
// leaves connection open
}

For automated testing purposes, it's usually easier to pass it in. This is called dependency injection.
When you need to write tests, you can create a mock database connection object and pass that instead of the real one. That way, your automated tests won't rely on an actual database that needs to be repopulated with data every time.

I personally work to centralize my data access as much as possible, however, if not possible I ALWAYS open a new connection in the other classes, as I find that there are too many other things that can get in the way when passing the actual connection object.

Here is a little more insight into this problem. I have a class that manages db connections, and have 2 classes that implement an interface. One of the classes is for SQL and the other is of OLAP. The manager is the one that knows which connection to use, so it could pass the exact connection to the type, or the type can create his own connection.

You can pass connection objects without any problem (for instance Microsoft Enterprise Library allows static method calls passing in a connection) or you could manage it externally its up to your design, there are not direct technical tradeoffs.
Be careful for portability not to pass an specific connection if your solution will be ported to other databases (meaning don´t pass a SqlConnection it you plan to work with other databases)

Setting up the connection is potentially expensive and potentially adds a round trip. So, again, potentially, the better design is to pass the connection object.
I say potentially, because if you are a Microsoft ADO app, you are probably using a connection pool....

I would suggest that you distinguish between the connection object and its state (open, closed).
You can have a single method (or property) that reads the connection string from web.config. Using the same version of the connection string every time ensures that you will benefit from connection pooling.
Call that method when you need to open a connection. At the very last moment, after setting up all of the SqlCommand properties, open the connection, use it, and then close it. In C#, you can use the using statement to make sure the connection is closed. If not, be sure to close the connection in a finally block.

I would use the web.config
<configuration>
<connectionStrings>
<add name="conn1" providerName="System.Data.SqlClient" connectionString="string here" />
<add name="conn2" providerName="System.Data.SqlClient" connectionString="string here" />
</connectionStrings>
</configuration>
Then you can reference it from anywhere in the application