Home Server
New Blog Posts: Merging Reports - Part 1 and Part 2

Two users running the same report problem

edited February 2004 in Server
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

Comments

  • edited February 2004

    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

    Best regards,

    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com
  • edited February 2004
    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


  • edited March 2004

    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

    Best regards,

    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com
  • edited March 2004
    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



This discussion has been closed.