I am trying to troubleshoot some deadlocking issues we are having. There are a few stored procedures that are updating a table and they often deadlock with the same single SELECT statement that is issued via a adOpenStatic cursor from a compiled VB application. The SELECT statement is called to populate a grid, and I can see that there are round trips to the database through the ADO cursor as a result of capturing profiler data. Onto my question -- I noticed in my profiler trace that there are many records for the ADO executed SELECT statement with event class 50 which is a SQL Transaction. However, I can only find records for these transactions with event subclass type 1 which is COMMIT transaction. I can't find any records with subclass 0 for these round trip cursor calls. Can someone explain how this is possible or what is going on? Is the transaction implicit in ADO and does it not show up in the profiler trace? For all the stored procedures that are running the updates, I can find subclass 0 and 1 for the SQL transactions, but for the ADO cursor-called SELECT, I can only find COMMITS. Any help would be appreciated. Thanks, Daniel -dataninja- "The normalcy of a database is inversely proportional to that of it's DBA."