Transactions and call stored procedures

[MNF]

It will be good to include a section (or add a reference to some existing article) how transactions are used when calling stored procedures. Something similar to https://stackoverflow.com/questions/19991609/ef6-wraps-every-single-stored-procedure-call-in-its-own-transaction-how-to-prev

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 1073c238-9389-d826-a696-f1108a4f2ce0
• Version Independent ID: cf56babd-def0-d76e-8eee-e33341b6a009
• Content: Transactions - EF Core
• Content Source: entity-framework/core/saving/transactions.md
• Product: entity-framework
• Technology: entity-framework-core
• GitHub Login: @roji
• Microsoft Alias: avickers

[roji]

@MNF I'm not aware of any specific EF transactional behavior around stored procedures. Assuming you're referring to executing stored procedures via raw SQL (DbSet.FromSql* or context.Database.ExecuteSql*), no transaction is implicitly created. Are you thinking of anything in particular?

[michael-freidgeim-webjet]

That’s what I initially was confused with. I’ve read some SO threads about EF6 automated transaction wrapper. I expected to find in this article information how transactions are used for stored procedures (DbSet.FromSql* or context.Database.ExecuteSql*) in EF Core , but didn’t find anything. Some tip/note that “In DbSet.FromSql* or context.Database.ExecuteSql* no transaction is implicitly created.” will be useful.

[roji]

We don't usually document stuff that EF doesn't do... It's generally easy enough to turn logging and see whether a transaction is created or not, no?

[michael-freidgeim-webjet]

1.I suggested to mention it, because the behaviour about automated transaction wrapper is different between EF6 and EF Core. We know that products are different, but it is not obvious that they are different for particular feature. 2.Do you write documentation to give people information how functionality works without need to try themselves? I personally even didn’t know that logging will show is transaction created and not.

[roji]

Specifically for users porting from EF6 to EF Core, a note in our porting guide may make sense.

But other than that, I'm not sure why someone would assume there's a transaction specifically around stored procedure calls. For the old EF6-related link you posted above, that seems like something that users would care about mainly if it causes problems for them (i.e. because the EF6-created transaction interferes with their own wider transactional logic), but I can't really imagine why an EF Core user without EF6 background would need to see a note about this. In general, docs are an art of balance - adding too many irrelevant notes creates lots of noise and makes it harder to read the docs.

[MNF]

Of course it’s your call to determine typical scenarios for your readers. My scenario was to search about transactions in EF when calling stored procedures, and first articles were about EF6 and this page about transactions in EF Core didn’t say anything. I believe that I am not alone.

[roji]

May I ask why you were searching specifically for transactions and stored procedures?

[MNF]

I have EF Core code that is calling stored procedure in Azure SQL Managed Instance database. Some calls to the stored procedure were timed out, and I wanted to understand were these calls partially processed or rolled back.

[roji]

Thanks for the details - SQL Server indeed does not implicitly place stored procedures in a transaction, so a stored procedure terminating for any reason leaves behind any changes. So it's the responsibility of the stored procedure to make sure there's a transaction internally.

We can consider adding a note in the docs for this.