It's a little hard to tell exactly how your code works now, and I think the answer depends on whether or not your current implementation is blocking the UI (i.e., by making a synchronous call to your DB DLL).
Now, if your call to the DLL is a synchronous one and it's blocking the UI then, yes, you might want to consider using a BackgroundWorker to do that work and allow your main UI thread to avoid hanging. You can refer to http://stackoverflow.com/questions/1259949/how-to-implement-progress-bar-and-backgroundworker-for-database-calls-c for some answers.
But you still need some mechanism for knowing the progress of your DB call, and it doesn't sound like the DLL exposes anything like that yet.
Just reading between the lines of your question, it sounds like you have some ability to modify the DLL. If so, then you should try to use a pattern that preserves decoupling between the DLL and your UI app when providing progress information. Your UI code should really be responible for updating itself based on some data that the DLL can provide in a loosely coupled way. I would suggest using either:
- A subscription model by listening on
an event published by some class in the
DLL; or
- A polling model to actively
monitor some data object implemented in the DLL on a periodic
basis (e.g., during a Timer Tick
handler).
Either way, you want to avoid tightly coupling the two layers together by coding the DLL to have intimate knowledge of your UI layer. Both of the aforementioned possibilities should allow you to keep your UI updating code on the main UI thread of your app executable in most circumstances, which is important if you want to avoid multithreading issues.