Мне действительно нужно использовать "SET XACT ABORT ON"?

Я считаю, что SET XACT_ABORT ON был требованием при выполнении распределенных транзакций.

из книг о строку: Xact_abort должен быть установлен для инструкций изменения данных в неявной или явной транзакции для большинства поставщиков OLE DB, включая SQL Server. Этот параметр не требуется только в том случае, если поставщик поддерживает вложенные транзакции. Дополнительные сведения см. В разделе распределенные запросы и распределенные транзакции.

XACT_ABORT действительно влияет на обработку ошибок: он будет прерывать весь пакет при возникновении ошибки и любой код, следующий за строкой, которая вызвала ошибку (включая проверку ошибок!) никогда не будет исполнять. Есть два исключения из этого поведения: XACT_ABORT заменяется TRY...CATCH (блок CATCH всегда будет выполняться, и транзакции не будут откатываться автоматически, а будут отображаться как uncommitable), а XACT_ABORT будет игнорировать RAISERROR.

Я понимаю, что даже если используется try catch и в блоке catch не используется оператор отката, любая транзакция, не подлежащая фиксации, будет откатываться, когда XACT_ABORT дальше.

есть предостережение, чтобы слепо всегда использовать SET XACT_ABORT ON; который сжег меня недавно.

я прочитал убедительный аргумент о StackOverflow, который предположил, что вы должны всегда использовать XACT_ABORT ON. я изменил систему, чтобы установить эту опцию при подключении. Кроме того, это приводит к повреждению данных и много боль.

begin transaction
try
    perform insert
    catch duplicate key violation and react appropriately

    perform more actions

    commit transaction
catch
    rollback transaction
end

кроме того, что ваши "дополнительные действия" больше не будет происходить в транзакции. Потому что хоть вы поймали дубликат ключа нарушении сервер больше не находится в операции:

begin transaction
try
    perform insert
    catch duplicate key violation and react appropriately
    transaction implicitly rolled back

    perform more actions

    commit transaction -> fails because not in a transaction
catch
    rollback transaction -> fails because not i a transaction
end

С тех пор я изменил свое мнение. никогда использовать SET XACT_ABORT ON.

редактировать: люди, кажется, думают, что проблема исходит от попытки позвонить ROLLBACK TRANSACTION в то время как не в транзакции. Они думают, что проблема может быть исправлена, не вызывая ROLLBACK если транзакция не выполняется.

давайте использовать некоторый псевдо-код, с имена изменяются для защиты NDA:

const
   SQLNativeErrorPrimaryKeyViolation = 2627; //Primary keys. 2601 is for other unique index

void x(String sql)
{
   database.Connection.ExecuteNoRecords(sql);
}

что является педантичным способом сделать этот ответ более читаемым; мы используем x для представления выполнения некоторого оператора SQL:

void DoStuff()
{
   x("BEGIN TRANSACTION");
   try
   {
      try
      {
         x("INSERT INTO Patrons (AccountNumber, Name, Gender)"+
           "VALUES (619, 'Shelby Jackson', 'W'"); 
      } 
      catch (ESqlServerException e)
      {
         //check if the patron already exists (or some other hypothetical situation arises)
         if (e.NativeError == SQLNativeErrorPrimaryKeyViolation)
         {
            //This patron already exists. Set their frob to grob because contoso the blingblong
            x("UPDATE Patrons SET Frob='Grob' WHERE AccountNumber = 619");

            //20110918: Dont forget we also need to bang the gardinker
            x("EXECUTE BangTheGardinker @floof=619");
         }
         else
            throw e;
      }

      //Continue with the stuff
      x("EXECUTE Frob('{498BBB4D-D9F7-4438-B7A6-4AB5D57937C0}')");

      //All done, commit the transaction
      x("COMMIT TRANSACTION");       
   }
   catch (Exception e)
   {
      //Something bad happened, rollback the transaction 
      //(if SQL Server didn't kill the transaction without our permission)
      x("IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION");


      throw e;
   }
}

XACT_ABORT ON круто, позволяет использовать его

Итак, этот код работает. Если есть ошибка, что мы ожидал, мы справимся с этим и продолжим. Это называется обработка ошибки. Если некоторые неизвестный исключения (то, что мы не ожидал), мы rollback любая транзакция, которая может быть в процессе.

теперь давайте посмотрим, если мы слепо следовать предложению, что XACT_ABORT всегда должно быть включено:

 DbConnection Connection()
 {
    if (_connection == null)
    {
       _connection = new SqlConnection();

       //It is generally recommended that you always have xact_abort on.
       //If a connection is closed with a transaction still in progress
       //it still leaves locks held until that connection is finally recycled
       //Also, when querying linked severs in a client-side transaction, the
       //operation won't work until xact_abort is on (SQL Server will throw an saying xactabort is off
       _connection.ExecuteNoRecords("SET XACT_ABORT ON");
    }

    return _connection;
 }

void x(String sql)
{
   database.Connection.ExecuteNoRecords(sql);
}

вы видите коррупцию, которая приведет в DoStuff?

DoStuff был правильно написан для обработки случаев ошибок. Но введение XACT_ABORT ON для подключения теперь вызовет повреждение базы данных. Для тех из вас, кто не видит ошибку, давайте пройдитесь по коду:

void DoStuff()
{
   x("BEGIN TRANSACTION");
   try
   {
      try
      {
         x("INSERT INTO Patrons (AccountNumber, Name, Gender)"+
           "VALUES (619, 'Shelby Jackson', 'W'"); 

      } 
      catch (ESqlServerException e)
      {
         //WARNING: WE ARE NO LONGER OPERATING IN A TRANASCTION
         //Because XACT_ABORT is on, the transaction that we started has been implicitly rolled back.
         //From now on, we are no longer in a transaction. If another error happens
         //the changes we make cannot be rolled back

         //check if the patron already exists (or some other hypothetical situation arises)
         if (e.NativeError == SQLNativeErrorPrimaryKeyViolation)
         {
            //WARNING: This update happens outside of any transaction!
            //This patron already exist. Set their frob to grob because contoso the blingblong
            x("UPDATE Patrons SET Frob='Grob' WHERE AccountNumber = 619");

            //WARNING: This stored procedure happens outside of any transaction!
            //20110918: Dont forget we also need to bang the gardinker
            x("EXECUTE BangTheGardinker @floof=619");
         }
         else
            throw e;
      }

      //WARNING: This stored procedure happens outside of any transaction!
      //If any error happens from
      //Continue with the stuff
      x("EXECUTE Frob('{498BBB4D-D9F7-4438-B7A6-4AB5D57937C0}')");

      //WARNING: This stored procedure happens outside of any transaction. It will throw:
      //   Msg 3902, Level 16, State 1, Line 1
      //   The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION.
      //All done, commit the transaction
      x("COMMIT TRANSACTION");       
   }
   catch (Exception e)
   {
      //If there was an error during Frob, we would want to catch it and roll everything back.
      //But since SQL Server ended the transaction, we have no way to rollback the changes

      //And even if the call to Frob (or Updating the patron's Grob, or Banging the Gardinder)
      //didn't fail, the call to COMMIT TRANSACTION will throw an error

      //Either way, we have detected an error condition that cannot be rolled back in the database


      //Something bad happened, rollback the transaction 
      //(if SQL Server didn't kill the transaction without our permission)
      x("IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION");


      throw e;
   }
}

код, который был написан правильно и работает, становится сломанным, вызывает ошибки и в худшем случае вызывает повреждение базы данных. Все потому, что я включил XACT_ABORT ON.

когда XACT_ABORT установлен в OFF в триггере,и я вызываю RAISEERROR в теле триггера, изменения не откатываются.