Hello,

I'm using the Oracle.OnOracleError event to modify the errormessages for the users. I'm also using the TApplicationEvents.OnException to log the errormessages. The problem is that the OnException also fires AFTER the OnOracleError.

Question 1 :

Is it possible to set a sort of Handled flag on the error, so that the OnException event doesn't fire anymore?

Question 2 :
Is it possible to check in the OnException event whether the Exception is an EOracleEvent or not?
The code:

procedure TFrm_Main.ApplicationEvents1Exception(Sender: TObject; E: Exception);
begin
if E is EOracleError then
//nagnag
end;

doesn't work

any help would be appriciated

Thx

[quote]Question 1 :

Is it possible to set a sort of Handled flag on the error, so that the OnException event doesn't fire anymore?[/quote]No, because it really isn't handled. To prevent propagation to the OnException handler, you will need to explicitly handle the exception in your code.
[quote]Question 2 :
Is it possible to check in the OnException event whether the Exception is an EOracleEvent or not?[/quote]Yes. The "if E is EOracleError" test works fine for me. Note that dataset exceptions are propagated as EDatabaseError exceptions.

Thx Marco

Testing for EDatabaseError did the trick. I was a bit confused here, because the help only mentioned EOracleError so i tested for that.

Thx Again

adbo1

How could I get the original EOracleError exception from the EDatabaseError one? IMHO when an exception is re-raised it should add more information, not hide existing ones.
Often Oracle error messages does not convey enough informations - the only way to undestand what's really wrong is to look at the query and have the error line/position.
I could use the OnOracleError hook, but I see no way to stop further exception processing from there.
I would use an EOracleError for non-dataset related classes, and a EOracleDatabaseError (a descendant of EDatabaseError) for dataset related classes, containing the original EOracleError informations.
It should not break compatibility and would not include DB.pas when not needed.

No information is lost, the EDatabaseError contains the same message text.

Sorry, but almost all informations (especially the error position within the query) are lost but the error message - and often Oracle error messages are very poor of useful informations. And I'd need to parse it even to get the error code.

It looks like DOA entered a "legacy" state when no real improvements are introduced or planned. Should we look for alternatives?

The error position is not part of the EOracleError class.

But via EOracleError I can access the "instance" that caused the error, and get those data, if available. If the EOracleError exception is no longer accessible I have no way.