This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(121.6, 94%, 21%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EN%3C/text%3E%3C/svg%3E)
Hello Experts,
Greetings to All ! In our environment, there exist a COBOL V9 version POD which connects to SQL server (2019) using ODBC driver V18. In this client-server design, during the query retrieval process from COBOL to SQL server , we are getting below error in SQL traces followed by request is getting failed at client side.
Here are the error messages:
· SQLCODE= 00003989 SQLERRMC = New request is not allowed to start because it should come with valid transaction descriptor
· No more lock classes available from transaction.
· New request is not allowed to start because it should come with valid transaction descriptor.
· Uncommittable transaction is detected at the end of the batch. The transaction is rolled back
What we tried ?
What are the recent changes ?
We are a Devops environment and changes here are very frequent. As part of recent cadence delivery there were some DML changes in SQL server and COBOL version is changed to V9.From then issue is active.
Apparently, as the trace is reporting errorcode (SQLCODE= 00003989) on SQL side, many are suspicious that problem exist from SQL side but the SQL error logs are certainly green and no other issues are reported during the query execution (Except trace reports error) . So pls check this issue and provide us pointers to get the actual root cause of this problem .Many thanks!
Regards,
Naren
Is there any particular reason why you run a distributed transaction? I ask this, because if you run it by happenstance, the solution is likely to be not use distributed transactions. Distributed transactions are all hunky dory when everything runs fine. When things fail - it's not fun at all.
The error messages you are seeing do indeed come from SQL Server, but I wonder it could be that things go wrong before these messages are produced, and the original error messages are lost. The last message shows that there is a CATCH handler, so things may be going wrong in the CATCH handler.
On my web site, I have an article Monitor Exceptions in Your Database, which describes how to set up an extended-events session that captures exceptions, and then how to read that session through a view. So you would set up this session, and when you get these errors, you check the view if there are any errors produced just before this. The view will also give you the statement that produced the error.
Have you tried to enclose the query or queries associated with this error in a 'begin distributed transaction' statement as explained here? On DML operations make sure you explicitly commit or rollback transactions. Have you tested with v17 of the ODBC driver?