ADO connection error handling

edited November 2006 in Server
?I have a couple of reports that are generated from a template volume
and rtm file where a parameter passed via the URL to the webtier is used
as a session parameter within the rbserver executable. That parameter is
then used to manipulate the ADO connection string and specify which
database to connect to.

i.e. webtier.dll?database=db1
This section works as planned and without error. My problem is, if a
database parameter is passed that is invalid, I of course get a 'TNS
could not resolve service name' error, followed by a 'TrsServer - Fatal
Exception'. The errors are displayed on the web server as a error prompt
box and the message is not returned to the webtier for display in the
browser until the prompt box is cancelled.

What I would like is for the rbserver to fail gracefully and return the
message on to the webtier for display in the browser without the prompt
box on the server but my attempts at this have failed and truthfully,
not really sure where (or how) I should be trying to handle this
exception.

Code that I am using in the Template Volumes BeforePublishReport event :

{...code that reads registry keys for userid and password ..}

dbinstance := aEventParams.SessionParameters['dbinstance'].Value;

try
ADOConnection1.ConnectionString := 'Provider=MSDAORA.1;Password='+passwor
d+';User ID='+userid+';Data Source='+dbinstance+';Persist Security
Info=True';

except
on E: EOleException do
{various attempts to handle the exception have been placed here}
end;

Any thoughts, suggestions, etc ????



--- posted by geoForum on http://delphi.newswhat.com

Comments

  • edited November 2006

    -------------------------------------------------------------------------------
    Tech Tip: RB Server - Exception Handling
    -------------------------------------------------------------------------------

    This article applies to processing that occurs on the report server. It does
    not apply to the webtier or client report.

    The report server is a multi-threaded application. Each report executes in a
    separate thread. Exceptions that descend from EReportBuilder are handled
    gracefully by the server - the exception is propogated back to the web tier
    or client report application. A web tier application will display an error
    page, a client report application will raise an exception in the client app.
    In both cases a descriptive message is included.

    An exception that does not descend from EReportBuilder error is considered
    fatal and will cause the server application to terminate. If ReportBuilder
    Services is being used to manage the server, then ReportBuilder Services
    will automatically try to restart the server application.

    ReportBuilder Server contains code to check for common exceptions that occur
    when loading and generating reports. These exceptions are re-raised as
    either EReportBuilder or a descendant of EReportBuilder error.


    Custom code that is added to the server should follow these same guidelines.

    Example:

    uses
    ppTypes;


    // define a custom exception class to use for all of your custom code

    ECustomReportBuilderError = class(EReportBuilderError);


    try
    {some processing here}

    except on E: EStreamError do

    raise ECustomReportBuilderErrorr.Create(E.Message);

    end;


    Note: The above example will trap an EStreamError and re-raise it as
    ECustomReportBuilderError. Other exceptions will be considered fatal.
    Therefore you will have to decide which exceptions are acceptable and which
    are fatal.



    --
    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com

    Best regards,

    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com
This discussion has been closed.