Post reply

Deadlocking calling Crystal Reports

  • July 13, 2005 at 1:13 pm

    #88110

    Hi all,

    I'm having a problem call crystal reports from our ERP system, that just started all of a sudden.

    Error running report.  There is no output file: C:\Program Files\MAPICS\SyteLine\TaskMan\Report\OutputFiles\amssuper7\matric_FinalServiceReport_Main_273068.pdfError... [2005-07-13 13:18:19]

    MainModule.Main:

    Failed to open a rowset.

    Details: ADO Error Code: 0x80004005

    Source: Microsoft OLE DB Provider for ODBC Drivers

    Description: [Microsoft][ODBC SQL Server Driver][SQL Server]Transaction (Process ID 115) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

    laceName w:st="on">SQLlaceName> laceType w:st="on">StatelaceType>: 40001

    Native Error: 1205

    SessionID = {73FC694C-37C0-4527-9AB3-216D0402EE09}

     

    This kind of confuses me since the transaction should be a read only.  It’s not like we’re updating the record or anything, just calling a SP as the underlying data source to the report.  It’s not just one report in general either.  It’s very sporadic.  I’m wondering if it’s a maximum SQL session for that user since all of our reports were created using the same SQL login? Or maybe something different???

    How in the world do I debug this...running trace routes as we speak to get more info

    Thanks

  • July 13, 2005 at 1:19 pm

    #574100

    It's probabely another table that needs to access this data with an opened transaction... Since no table can release the lock, it deadlocks...

    can you run this next time??

    exec sp_who2

    find the lines with blkby different that -

    then dbcc inputbuffer (spid) to see the statements executed by each spid... this will tell you where to look for the dead lock.

  • July 14, 2005 at 6:36 am

    #574328

    You're going to have to, minimum, set the traceflag 1204 to on. That will spit a bunch of information into your sql error log file that you can use to identify the two processes that take part in the deadlock. MS has a great little white paper on the topic here:

    http://support.microsoft.com/default.aspx?scid=kb;en-us;832524

    ----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply