ADO connection error handling

rbuser

?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

nardmoseley

-------------------------------------------------------------------------------
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