Quiet BackgroundWorker Exceptions

The System.ComponentModel.BackgroundWorker catches all of its exceptions as well as those emanating from the delegate that you wired up as a DoWorkEventHandler. If you don't check the e.Error property of the RunWorkerCompletedEventArgs passed to the delegate you wired
up as a RunWorkerCompletedEventHandler then you've set yourself up with a real trooper of a BackgroundWorker. All hell could break loose during its processing but it won't make a peep!

Spinning off threads via:

 
 Thread th = new Thread(new ThreadStart(myThreadStartMethod));
 th.Start();

Is not nearly so tolerant.

        private void backgroundWorker1_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e) {
           
            // !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
            // IF YOU DON'T CHECK e.Error != null THEN BAD THINGS CAN
            // HAPPEN IN YOUR WORKER BUT NO ONE WILL EVER KNOW!!!!!!!
            // !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
            if(e.Error != null) {
                MessageBox.Show(e.Error.Message);
            }
            else if(e.Cancelled) {
                // Next, handle the case where the user canceled
                // the operation.
                // Note that due to a race condition in
                // the DoWork event handler, the Cancelled
                // flag may not have been set, even though
                // CancelAsync was called.
                resultLabel.Text = "Canceled";
            }
            else {
                // Finally, handle the case where the operation
                // succeeded.
                resultLabel.Text = e.Result.ToString();
            }

            // Enable the UpDown control.
            this.numericUpDown1.Enabled = true;

            // Enable the Start button.
            startAsyncButton.Enabled = true;

            // Disable the Cancel button.
            cancelAsyncButton.Enabled = false;
        }

Checking Status of Currently Open Cursors in ORACLE

Pesky too many open cursors error from ORACLE can be investigated with the help
of the following code:

--total cursors open, by username & machine
select sum(a.value) total_cur, avg(a.value) avg_cur, max(a.value) max_cur,
s.username, s.machine
from v$sesstat a, v$statname b, v$session s
where a.statistic# = b.statistic# and s.sid=a.sid
and b.name = 'opened cursors current'
and s.machine in ('MY Machine', 'His Machine', 'Her Machine')
group by s.username, s.machine
order by 1 desc;

Visit this nice link for more info