|
I use the ODBC API to execute SQL (SQLExecDirect) and to trap errors that result from that execution (SQLGetDiagRec). Lets say I insert into a table that has a trigger and somewhere in that trigger there is an exception. Right now, SQLGetDiagRec, just returns a basic message (e.g. 'divide by zero'). It doesn't return any details about which trigger, procedure or function this error happen to occur in. In theory, SQLGetDiagField can be used to get additional details about an error. The SQL Server folks added their own custom field called SQL_DIAG_SS_PROCNAME which can be used to get the object that actually triggered the error. Is there an equivalent for SQL Anywhere? |
|
Try calling TRACEBACK(*). You should carefully test this to make sure the results are still available by the time your application discovers there's a problem. Another approach is to add EXCEPTION handlers to BEGIN blocks (mostly stored procedures in my case, triggers in your case) to log exceptions to a diagnostic table... that may be too much work, but (a) it's just additional code that doesn't disrupt any existing code in the triggers, (b) it means the client-side error handling can kept very simple, and (c) it is a blessing in the long run if you're doing a lot of development, especially massive enhancements. |
