In a WPF application I use LINQ to SQL queries inside try - catch constructions to process exceptions, in case there is something wrong with DB server connection.
The problem is - I have some queries executing on a timer-polling basis. So, if connection fails, I have numerous long queries attempts and UI is freezing.
What is the standard way out? I would like to have easy lightweighted way of constant checking if db connection is OK and then do all the stuff with all my queries.
Why not move your polling queries onto their own thread so they won't freeze the UI? Then they can raise a message or event to your main UI thread and you can handle it there (pop up an error message, etc).
run it in a backgroundworker thread, or a separate thread entirely.
Work should not be done on the UI thread, unless it directly pertains to the UI itself. BackgroundWorker is an object that makes threading stuff like this really easy. For a tutorial see this entry. It explains what Background worker does and how to use it.
If you do work on the UI thread, you are stealing CPU cycles away from the UI causing it to feel slow to the user. Running the work on it's own thread and then updating the UI is the best way to do it. That way the user can do other stuff and the UI responds properly.