<< The timer runs in its' own thread, so ProcessMessage should give the message loop a breather for screen updates. >>
Is this true? I was under the impression that the timer was actually run inside Windows, which dispatches a message (WM_TIMER, I think) back to the application's main thread when the timer "goes off". If the main thread is blocked (as with a long call into the RBENGINE.DLL) it strikes me that the timer message might not make it, or might not be seen by the application in a timely fashion. Have you actually tried this -- setting a timer and then somehow blocking on the winmain() thread to see if the timer gets executed? If this is the case, I imagine you might be able to work around it by including a call to a stored procedure in you SQL statement; a stored procedure that include a PROCESSMESSAGES statement. But it would slow down your SQL. -- Larry
