title: Teradata: How do you debug "Transaction ABORTed due to Deadlock" errors?
body: <p>Lately, we've been getting hit with the error <code>Transaction ABORTed due to Deadlock</code> when we go to update a record in one of our tables.  Something is placing a lock on this table and it's not being released, but I have spent literal work days trying to track it down and it eludes me still.</p>
  
  <p>While the error is random, I do know what repetive cycle of steps I need to repeat in order to eventually trigger it.  However, I've queried dbc.DBQLogTbl and looked at all the SQL that's been executed 2 minutes before and after the error occurs and nothing appears to be selecting from any table without an access lock.  Furthermore, after the error occurs, I will hit F5 repost the web form back to the server to repeat the exact same set of updates and it will work.</p>
  
  <p>My hunch is that some process outside our ASP.NET application is locking the table since I've checked all the SQL that's being executed by our application.  I think there has to be a way to find out what specific SQL has been executed that has placed locks on a table.</p>
  
  <p><strong>8/9/2012 Additional info:</strong>  All of the following is occuring in this order within the same transaction based on what I am seeing when querying <code>dbc.DBQLogTbl</code> and ordering by <code>firststeptime</code>:</p>
  
  <ul>
  <li>update employee table</li>
  <li>locking row for access select * from employeesecurity where empid = X (do this to get current employee record to see if anything has changed)</li>
  <li>if there is a change, update aforementioned employeesecurity record</li>
  <li>update employeeconfig table (deadlock error always occurs here)</li>
  </ul>
  
  <p>I didn't mention this before, but the deadlock error is occurring on a table that I am not selecting from at all.  When the page loads, I do read from an employeeconfig view, but <code>locking row for access</code> is specified in the view.</p>
  
  <p>Answer to Rob's 4 questions:</p>
  
  <ul>
  <li>It's only one transaction.</li>
  <li>As I stated in my latest update, the table that's locked is not even the table that's being selected from.</li>
  <li>All queries use <code>locking row for access</code></li>
  <li>We are selecting from the view <code>employeeconfig</code>.  This view selects from the <code>employeeconfig</code> table using <code>locking row for access</code>.  We do not use <code>locking row for access</code> when querying the view itself.</li>
  </ul>
  
  <p>As far as handling the deadlock, I'd rather not have the code just try to resubmit it as this seems like a problem that needs to be fixed.  As you said, Rob, it's possible that my access to <code>dbc.DBQLogTbl</code> is limited, so perhaps I just cannot see everything that is occurring.  I've been in contact with the DBA and will follow up again today.</p>