It sounds like your UPDATE is closing the connection and your background thread is attempting to use it to query. If im reading between the lines correctly, you have created a connection object as a stateful member of your winform which is being opened once and possibly being closed after an UPDATE (or automatically by the connection pool). Either way you need to take a step back here and think about how your doing things.
Your update and select methods (hopefully in separate classes to your forms) should take care of opening and closing connections exclusively rather than in a statefull way (i.e. the scope of the connection remains in the methods). The ADO connection pool will take care of optimising connections for you.
I also recommend you use disconnected data structures such as DataTable and DataSet rather than DataReader as these keep the connection footprint between the client and the database light. You can happily process and pass around these structures without maintaining an open connection which DataReader requires. Ideally you would populate a light-weight object structure rather than passing DataSet around too much as it does carry some memory overhead - there are a bunch of other reasons for this too e.g. type safety.
There is nothing wrong with calling a method which executes queries on multiple threads as long as the scope of the connection is limited to the method. For example:
public static DataSet GetWebStatsData()
{
DataSet StatsData = new DataSet();
using (OleDbConnection conn = new OleDbConnection(ConnString))
{
using (OleDbCommand cm = new OleDbCommand(GetDataProcedure))
{
using (OleDbDataAdapter adap = new OleDbDataAdapter(cm))
{
cm.Connection = conn;
conn.Open();
adap.Fill(StatsData);
conn.Close();
}
}
}
return StatsData;
}
You can happily call the above method from many threads simultaneously and it should work. I have worked on applications making heavy use of the threadpool executing in some cases scores of queries simultaneously with no ill effect. Where this is happening i would recommend setting a maximum size to the ado.net connection pool as it can grow quite large if left un-guarded (there is typically a connection string attribute for this like 'Max Pool Size=n'). Ado.net will marshal the connections on your behalf so there is a lot of plumbing to leverage in the framework here.