title: SQL Error "uncommittable transaction is detected at the end of batch" without transactions on db
body: <p>I'm facing the following problem at different points of my code.
  An SqlException is returned from DB (SQL Server) with message "Uncommitable Transaction is detected at the end of the batch. Transaction is Rolled Back" after calling a Stored Procedure. Stored procedure structure follows this example:</p>
  
  <pre><code>USE [EXAMPLE_DB]
  GO
  
  SET ANSI_NULLS ON
  GO
  SET QUOTED_IDENTIFIER ON
  GO
  ALTER PROCEDURE [dbo].[sp_ExampleStoredProcedure]
  @Parameter INT, @AnotherParameter INT
  
  AS
  BEGIN
      BEGIN TRY
  
      SET NOCOUNT ON;
  
  
      DECLARE @Variable INT;
      DECLARE @AnotherVariable CHAR;
      DECLARE @ErrMsg VARCHAR;
  
      SET @ErrMsg = '';
  
      /*Doing Some Stuff Here (Select, IF-THEN, etc...)
  
              /* I call another stored procedure */   
              EXECUTE [dbo].[sp_SecondStoredProcedure] 
                         @Param = 'Blabla'
                        ,@Param2 = 'BlaBlaBla'
  
  
              /*Here I handle some custom output parameters from second stored                           
                       procedure to handle errors */
  
  
  
                      /* Other stuff here */
  
  END TRY
  
  BEGIN CATCH    
          SET @CustomExitCode = 'XXXXX';
          SET @ErrMsg = (SELECT ERROR_MESSAGE()); 
  END CATCH;
  
  END
  </code></pre>
  
  <p>As you can see, inside stored procedure there's no transaction handling.
  I handle transaction code-side (C#) using TransactionScope class, calling various stored procedure inside transaction scope, including the one above (which is the one failing).</p>
  
  <p>Question is: why does SQL talk about Uncommitable Transaction, if I have no transactions SQL side, but only a try-catch block, with all transaction handlings performed on the code instead?</p>
  
  <p>I've already searched around the web and found a lot of materials about the Uncommittable Transaction error, but everywhere there is transaction handling on the SQL-Side, actually.</p>
  
  <p>I hope I have explained the issue in an understandable manner.
  I'm obviously available for any further info.</p>
  
  <p>Thank you very much for your help! </p>
  
  <p>Cheers,
  Gabriele</p>