I saw that instead of just raising an exception, sometimes DOA handles the exception and shows a dialog by itself (using 4.0.7).

The problem surfaces when DOA are used in a service or a DCOM server that runs under a specific user credential: the application has its own windows station and thereby the dialog does not appear anywhere - the service/server will look simply blocked and it can be only killed.

DOA should not show any dialog by itself but when in design mode, perhaps. It should never act that way at runtime. I do not know if it was fixed in a later release, but that's really a big issue but in plain C/S applications.

Thanks to Sysinternals' ProcessExplorer for being able to identify where the server was blocked.

Direct Oracle Access does not show any message boxes. If an exception is displayed in a message box, then this indicates that the exception is not handled by the application.

I have bought the DOA code. In several places it raises an exception, then traps it and calls ShowMessage(), sometimes re-raising the exception, sometimes handling it. Check for example:

TOracleSession.ReactivateDataSets;
TOracleTableInfo.GetColumns;
TRecordDataList.RecordAt(Index: Integer): PRecordData;
TOracleDataSet.QueryRecord: Boolean;

Moreover TApplication.ShowExceptio() uses MessageBox(), not ShowMessage(), and its dialog box has the STOP icon, while DOA using ShowMessage() display dialogs with no icons. That's why I was lead to inspect the code.

As I wrote in the previous post, I am still using 4.0.7 (Delphi 2007). Didn't check if it was fixed in a newer release.

Those are design-time errors or application errors (e.g. a filter expression).

Which error message do you get?

The one raised by TRecordDataList.RecordAt() when using a M/D with each dataset set to unidirectional (using Datasnap and TDatasetProvider, D20007, DOA 4.0.7), see my other post about it.
It's ok for design time errors, but application error shouldn't be reported that way - as noted services and DCOM server may hang that way - and it could be tricky to find what really happened. I trap and log errors to a file or the event log, but I can't if the exception is trapped and a dialog shown in another windows station.