You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently there is no way to obtain the point of stored procedure that faults (i.e. when error occurs in some sp "A" we can not see on *server* side what exact statement lead to error). Consequently we can not to automate such task as logging of errors by SERVER program units.
I think that introducing of two new context variables will be useful. These variables should store the name of currently executing SP and the LINE of currently executed statement in this SP.
In such case if we had DB-level trigger that fires on any error the task of PRECISE logging could be done easy (by call in autonomous transaction INSERT INTO T_LOG ... from this trigger; no need to write thousands WHEN-handlers in each SP).
The text was updated successfully, but these errors were encountered:
Submitted by: @pavel-zotov
Votes: 2
Currently there is no way to obtain the point of stored procedure that faults (i.e. when error occurs in some sp "A" we can not see on *server* side what exact statement lead to error). Consequently we can not to automate such task as logging of errors by SERVER program units.
I think that introducing of two new context variables will be useful. These variables should store the name of currently executing SP and the LINE of currently executed statement in this SP.
In such case if we had DB-level trigger that fires on any error the task of PRECISE logging could be done easy (by call in autonomous transaction INSERT INTO T_LOG ... from this trigger; no need to write thousands WHEN-handlers in each SP).
The text was updated successfully, but these errors were encountered: