STATUS_OPERATION_NOT_SUPPORTED_IN_TRANSACTION (0XC019005A) – Fix Now

You're stuck in a transaction and SQL Server won't let you out

You ran a command and got hit with 0XC019005A. It's not a cryptic hardware failure. What's actually happening here is simple: you're inside an open transaction—either explicit or implicit—and you tried to perform an operation that SQL Server refuses to execute unless it's outside that transaction context. The fix is almost always to commit or rollback that transaction first.

The immediate fix

1. Identify the open transaction – Run DBCC OPENTRAN in the same session. It'll show you the oldest active transaction. Or use SELECT @@TRANCOUNT – if it returns 1 or more, you're inside a transaction.
2. Commit or rollback –

   COMMIT TRANSACTION;

   or

   ROLLBACK TRANSACTION;

3. Retry your original operation – That command should now run clean.

This works every time because SQL Server's transaction engine enforces a rule: certain operations—like database-level changes (ALTER DATABASE, CREATE DATABASE), some system stored procedures, or operations that require a new transaction context—cannot be nested inside an existing transaction. The error is your guardrail.

Why this happens – the real cause

The error code 0XC019005A maps directly to STATUS_OPERATION_NOT_SUPPORTED_IN_TRANSACTION in the Windows NT status system, but in practice you'll see it from SQL Server. The trigger is almost always one of these:

• Implicit transactions enabled – If SET IMPLICIT_TRANSACTIONS ON is active, every SELECT, INSERT, UPDATE, DELETE starts a transaction automatically. You forget to commit, then run a DDL command like ALTER TABLE – boom, error.
• Explicit transaction left hanging – You started a transaction with BEGIN TRANSACTION, ran some DML, then tried to execute a non-transactional operation without closing it.
• Nested transactions from application code – A stored procedure or ORM (Entity Framework, NHibernate) opens a transaction internally, while you're already in one. The inner attempt to commit or rollback can hit this.

I've seen this most often when someone runs a backup or a database restore inside a transaction – SQL Server flatly refuses. Same with DBCC SHRINKDATABASE or ALTER DATABASE SET READ_ONLY.

Less common variants

Sometimes the error appears in linked server queries. If you're running SELECT * FROM [LINKEDSERVER].[DATABASE].[SCHEMA].[TABLE] while inside a transaction, and the remote server doesn't support distributed transactions, you'll get this. The fix is to disable distributed transaction coordination:

SET XACT_ABORT OFF;
SET REMOTE_PROC_TRANSACTIONS OFF;

Another variant: you see it in PowerShell SQL Server module scripts where you use Invoke-SqlCmd with -Query inside a PowerShell transaction block. The module silently opens a transaction, and certain operations (like RESTORE) hit the wall.

Also, watch out for sp_addlinkedserver or sp_serveroption inside a transaction – those are system-level changes that can't be rolled back.

Prevention – don't get caught again

• Check @@TRANCOUNT before any DDL or system operation – Write a guard in your scripts:

  IF @@TRANCOUNT > 0
  BEGIN
      PRINT 'Transaction detected – aborting';
      ROLLBACK;
  END

• Keep transactions short – Don't wrap a whole batch in BEGIN TRANSACTION. Only wrap the specific DML that needs atomicity. Everything else runs outside.
• Use SET IMPLICIT_TRANSACTIONS OFF unless you really need it. Most people don't. It's a setting that bites you when you least expect it.
• Test your ORM's transaction behavior – Entity Framework's Database.BeginTransaction() often wraps multiple operations. If you mix raw ADO.NET commands in the same session, you can get into this state. Explicitly close or dispose the transaction before running anything else.

Bottom line: 0XC019005A is SQL Server telling you 'you're in a transaction and this operation can't go there.' Commit or rollback, then proceed. It's not a bug – it's a safety net.