Two users running the same report problem

rbuser

If two users are running the same report to the same database the
RBserver has fatal errors when both users are paging through the data.
The report has 142 pages of data and the error occurs at different pages
at the beginning, not able to get the error on the same page. The
database connection is set to dirty read, so there is no locking problem.

Discover this while walking a user through how the web reporting works
and was able to duplicate the errors.

Any suggestions on how to avoid the conflict? Not sure this would
happen that often, but it would be nice to avoid.

Thanks,
Dave Allen

nardmoseley

There is nothing in ReportBuilder that would cause such a limitation.

1. Make sure that the report has a thread-safe environment in which to
execute. This primiarly means definining a named connection (and a session
if you are using BDE). See RBServer\Demos\Servers\3. Explorer Databases for
examples.

2. As a test create a non-server based version of the report. Put the report
in a small application. Then run two instances of the application on your
machine and try to run the report from each app instance at the same time.



--
Nard Moseley
Digital Metaphors
http://www.digital-metaphors.com

rbuser

I have cloned the rbReportTemplateVolume to look at an Informix db and
have added some code for using the correct db name, but otherwise it's
the same program. And the report works when not using the RBserver.
Also the RBserver keeps connections to the database after the report has
completed. How would I end the connection or when should the connection
end? If the web interface is going through the cache, is the db
connection no longer needed? Should I have code in the
rbReportTemplateVolume to terminate the connection at some point? Maybe
I should drop the connection on the formDestroy. What do you think
would be the best approach?

Dave

nardmoseley

The ReportVolume.Publishing options can be used to control whether reports
are generating Incrmentally. For performance, I recommend using the
incremental report generation - which is the default.

Both the report server and the webtier perform caching to maximize
performance.

For each report request a new instance of the ReportVolume module will be
created. The ReportVolume will be destroyed when the session times out due
to inactivity or when another report for the same session is requested. I
would think that the database connection would be terminated when the report
volume is destroyed.





--
Nard Moseley
Digital Metaphors
http://www.digital-metaphors.com

rbuser

The report connection is not terminated, ever, or until the rbserver is
terminated. Had to check if the database component was nil, since at
first it is and generates an error.

I added a disconnect as:
procedure TdmReportTemplateVolume.rsReportTemplateVolume1Destroy(
Sender: TObject);
begin
if ( ( RbDb <> nil ) and
( RbDb.Connected ) ) then
RbDb.Connected := False;
end;

I'm thinking the report creates a cursor with the same name and both
reports are using the same cursor and bump into each other. That would
explain all the locks the report connections has accumulated.

Dave