dietztm (11/30/2015)
Your trigger (or auditing query) doesn't need to be visible to the user, it can just spam the devs until they fix it. Also talk to your boss about your job role... if you are a DBA, why are you getting stuck with debugging UI code?
I am a Project Manager for the company that provides the software - I am not the DBA for the system, but I have way more DB experience than anyone else here (30+ years with Oracle, SQL Server, Ingres, DB2, Sybase, and other databases), so I am frequently the "go-to" guy for anything related to the database. (I also reverse-engineered the multiple databases used by the product to create a "data dictionary" for our customers, and I may actually know more about the database structure and relationships than the developers at this point.)
The agency has their systems locked down in a private intranet - no Internet access, so the only persons I can "spam" are myself and one other person - we are the only two vendor personnel authorized to access the system.
And - any changes to the live production system have to go through an extensive testing process before deployment - it took fewer hours for me to track down the problem using audit trails and the source code than it would have taken to go through the production update process to get some additional information about the bug.
The system DBAs (agency personnel) don't make any system modifications unless there was an emergency outage issue. All product problems are referred to me to get resolved either by myself or by the developers (located in a different State and with no authorized access to the Agency's systems). Since they don't have access, I usually try to track down the bug source and send them the information they need to make the change in their source repository and do a formal release.