To answer your question "How do I access…": you should understand that there is no difference between threads in this respect. Due to the timing of database access, you should really create a separate thread for your database operations in many or most of the cases. This should not create any problems. If you have a problem of merging, it is not related to the thread you are running.
[EDIT]
In response to follow-up discussion on threading(see below):
So,
BackgroundWorker
is a simplified ready-to-use way of threading; it's more adequate to temporary task. Most database communication last about the run time of the whole application.
You need to do all database operations in the same thread (per database server); and this thread should not be the UI thread. Instead of creation of a thread from time to time, it's the best to create a background thread in the very beginning of the application and use it all the time until the whole application process terminates. You need to reuse the same very thread each time you need to work with the same database server, feeding data (for example, command or other request) to the thread as it is needed.
First of all, such thread should be created using the constructor
System.Threading.Thread.Thread
. The best way to use the thread is a thread wrapper. I helps to encapsulate thread data, avoid parametrized thread start (which is bad due to required type case); as you can pass an instance (non-static) method to the thread constructor, you pass an implicit "this" parameter (a reference to the wrapper instance), and hence, provide the access to all wrapper member. You can synchronize access to those members from its encapsulated thread and "foreign" thread (say, a UI thread) using lock or other thread synchronization primitives. That is, you centralize thread-safety in a wrapper. Too many benefits to miss this opportunity. Please see my posts on thread wrapper:
How to pass ref parameter to the thread[
^],
change paramters of thread (producer) after it started[
^] (this one with lock).
Now, you feed data to the thread via the wrapper. In there is not a job for a thread, is should be kept in a wait state wasting CPI no time until waken up by some event with data feed. The best way to do that is using a blocking queue. It can be a queue of data element ("tasks") but it could be event a queue of delegate instances (semantically, direct instructions on what to do). The principles of such queue are very similar to inter-thread invocation applied to UI thread. Please see my Tips&Tricks article where I provide a complete source code with comprehensive code samples:
Simple Blocking Queue for Thread Communication and Inter-thread Invocation[
^].
You also should be able to notify UI thread from you non-UI thread, just to update the views, etc. So, you need to use invocation. Please see my past answers where I explain it in detail:
Control.Invoke() vs. Control.BeginInvoke()[
^],
Problem with Treeview Scanner And MD5[
^].
See also more references on threading:
How to get a keydown event to operate on a different thread in vb.net[
^],
Control events not firing after enable disable + multithreading[
^].
—SA