Hi Andrew,

SystemError event is last-resort with limited recovery options. Also, context info is limited to what the Error object can tell you. And even if you decide to recover (i.e. let your application continue) your call stack has been flushed.

I suggest you consider using exception handling because you can localize recovery and error corrections. Also, your code can recover and continue when that is a relevant recovery action. Where SystemError is application wide, your TRY-CATCH can be implemented at whatever position in your code, you find relevant.

I prefer using exception handling - especially when calling web services, using OLE Automation, or otherwise interacting with code that throws exceptions.

Anyways, the previous answers are definitely worth pursuing when you have to do error handling in the SystemError event.

HTH /Michael

It is pretty common for applications to record system/database errors in a database table. You can add an error viewer window to the app or as a separate program.

Hi Andrew;

   I have extensive error handling in my frameworks. You are most welcome to check out the code and borrow whatever you need to add to your error handling requirements. My suggestion is to download the example OrderEntry App built from the frameworks and check out the System Error event coding on the Application object and then the corresponding "oe_systemerror" event of the Application Controller (nc_app_controller_master).

  Note that the code in the "oe_systemerror" event will handle:  Native, Windows Service, Windows System Tray,  Web and Mobile (PowerServer) based running Apps.

HTH

Regards ... Chris