More on RB and Threads

rbuser

We've realized that since some of our RAP pass-thrus access the
database. a TppPageRequestThread will end up calling code that is
accessing the TnxSession that our main program (thread) is also
accessing, and this we think is the source of yet more NexusDB database
errors our customers have with "System Has been illegally re-entered".

We've worked out a solution for our RAP stuff, but before we code it up
I have a general question about the difference between
TppReport.BackgrounPrintSettings and
TppReport.previewFormSettings.SinglePageOnly. In the RB Help there is
extensive information and precise instructions on how to implement RB
with BackgrounPrintSettings enabled (we have it turned off). But for
PreviewFormSettings.SinglePageOnly (which is FALSE by default, so
threading is on) there is just a "Set to True to use the old single page
viewer." - i.e. no warnings at all about the implications of using this
background thread. Is there a significant difference to how the
background thread is managed in each of these two options, where one is
relatively thead-safe so can be on by default and the other not?

TIA, Paul

nicocizik

Hi Paul,

Background printing and Multi-Page Previewing are two separate features.
Though they do use some of the same mechanisms to function.

Background printing is meant to happen completely in the background, out
of sight, while the rest of ReportBuilder (and your application) is
still being used. This is why in the documentation, we lay out exactly
how to create a independent container so no conflicts arise.

For Multi-Page viewing, the report pages are generated in a background
thread so the user does not need to wait for completion to begin viewing
and navigating pages. In this case, it is already assumed that most of
the reporting aspect of the application is separated from the rest of
the app.

Occasionally conflicts arise especially when a visual control shares the
same dataset as the report. This can usually easily be solved by
separating the two. If not, SinglePageOnly := True.

In your case, it appears NexusDB is very picky about which threads are
accessing data so it is imperative that the reporting aspect of your
application be independent from the rest of the application during
generation.

Note that in most cases, everything simply works. There are only a few
edge cases such as this one that we have found that require additional
steps to get working.