Hi Igor;

  FWIW:  Never use (code) the RetrieveRow event anywhere period. It's a huge performance degradation within any PB App. Even a blank line in that event can slow your DBMS retrievals down considerably!

  Instead, use the RetrieveEnd event to capture the total # Rows that were transmitted. Then until that happens, use an animated progress bar to "simulate" DB progress in a timer loop that only checks if the RE event was completed. Otherwise, just bump the progress bar a bit to give the App User the "illusion" of % completed. As long at the progress bar keeps moving, the App user knows there is "work in progress".

Just my $0.02.  HTH

Regards ... Chris

What is the problem you are trying to solve with multi-threading, Igor?

Are you wanting to free up the GUI from a long-running database retrieval? Speed up the elapsed time it takes to perform a series of database retrievals? Run multiple reports simultaneously? Handle large volume(s) of data retrieval more quickly?

Multi-threading is not a magic pill that will solve a multitude of performance issues, and as you are seeing, it is not a simple thing to utilize in PB. Depending on what you are trying to accomplish, there can be trade-offs. For example, while the use of multi-threading can help improve the user's perception of performance for a long-running database retrieval, it is a poor solution for database retrievals that return very large result sets.

Perhaps if you could explain the big picture, we could provide you with some suggestions.

The usual way to get information back from a thread: Create a nvo as callback object. This callbackobject should have a variable with a window to inform. Set this callback object to you nvo you ar eusing in the thread.

Post an event or function in your callback object from retrieverow event. In this event/frunction you can change the window (progressbar or whatever).