Get the 2026 .NET Developer roadmap here → https://the-dotnet-weekly.ck.page/2026-roadmap
Want to master Clean Architecture? Go here: https://bit.ly/3PupkOJ
Want to unlock Modular Monoliths? Go here: https://bit.ly/3SXlzSt

EF Core transactions look simple on the surface, but this is one area where a lot of developers get tripped up.

In this video, I break down the difference between implicit and explicit transactions in EF Core, and explain when SaveChanges() is enough versus when you need to take control yourself. The key rule is that EF Core gives you an implicit transaction when you call SaveChanges() once and only use tracked changes before that.

From there, I walk through the cases where things stop being safe:
- mixing tracked changes with raw SQL
- using ExecuteUpdate / ExecuteDelete
- calling SaveChanges() multiple times in the same flow

These are the scenarios where you can end up with partial updates and inconsistent data if you do not wrap everything in an explicit transaction. In the video, I show how to fix that with BeginTransaction and why it matters in real applications.

If you are building real-world .NET applications with EF Core, this is one of those topics you need to understand well.

Working With Transactions In EF Core
https://www.milanjovanovic.tech/blog/working-with-transactions-in-ef-core

Check out my courses:
https://www.milanjovanovic.tech/courses

Read my Blog here:
https://www.milanjovanovic.tech/blog

Join my weekly .NET newsletter:
https://www.milanjovanovic.tech

Chapters

We Are .NET

EF Core's implicit transaction covers a single SaveChanges call using the change tracker, but breaks down when mixing raw SQL, ExecuteUpdate/ExecuteDelete, or multiple SaveChanges calls. The fix is to wrap all related operations in an explicit transaction using DbContext.Database.BeginTransaction(), ensuring either all changes commit or all roll back. Practical demos show the pitfall and the correct pattern for each scenario, including EF Core's automatic savepoint behavior when combining bulk operations with SaveChanges inside an explicit transaction.

Stop Making This EF Core Transaction Mistake