Our testing team said too much was broken in our application for them to proceed. They are a pretty thorough bunch. A trouble ticket was submitted with detailed steps and screen shots of the problems.
I could not duplicate the first problem. So I asked a tester to show me the problem. She could not duplicate it either. But she gave me access to her environment. And I studied the data the application was using when the problem happened.
Next I went into our log database table. Sure enough I found an entry with this tester's user ID. The log entry gave me the stored procedure where the error occurred. I traced through each statement the stored proc executed. Every time I ran the SQL manually in the test environment. I finally got to a statement where I replicated the Oracle error. The source of the problem? Bad data. I like when it is not the application's fault.
Using this same technique I got down to the procedure where the other errors were occurring. This time I was not able to duplicate the problem by running the SQL manually. After challenging all my assumptions, I realized I was logging in as the schema owner. So instead I got the testers login and password and tried again. Bam. It was a permissions issue. I get to forward these to our DBA Team. Problem was corrected immediately.
Reproducing a Race Condition
-
We have a job at work that runs every Wednesday night. All of a sudden, it
aborted the last 2 weeks. This caused some critical data to be late. The
main ...