Is BulkSaveChanges creating a savepoint?
According to EF Core's documentation a savepoint is automatically created in case a transaction exists when calling SaveChanges. In case of failure EF then automatically rolls the transaction back to that savepoint.
Does BulkSaveChanges also automatically creates such a savepoint if a transaction exists and is the transaction automatically rolled back to that savepoint in case of an exception?
Thanks for your help!
Hello @buthomas,
We currently do not support savepoints in the same way EF Core’s SaveChanges handles them internally when a transaction is already in progress.
Thanks for bringing this to our attention — we weren’t aware of this behavior, so we’ll investigate whether we can align our implementation with SaveChanges.
Best regards,
Jon
Hello @buthomas,
After reviewing this request, we are currently working on adding support for EF Core 10.
Would it be fine with you if we add this only to EF Core 10, since it involves a kind of breaking change?
Best Regards,
Jon
Hi @JonathanMagnan
Thanks for your responses.
Changing this with EF Core 10 is fine for us. We made some changes on our side so that we do not rely on the automatic revert to savepoints anymore.
Hello @buthomas,
The v9.104.0.0 has been released.
We decided to include the SavePoint logic from EF Core 5 as it was originally introduced.
Let me know if everything works as expected. Thanks again for bringing this to our attention.
Best Regards,
Jon
is there a way to disable this behaviour? we currently facing the error :
Microsoft.Data.SqlClient.SqlException (0x80131904): Creating a savepoint is not supported with memory optimized tables
because of some memory optimized tables which were neede because some performance degregation
Hello @andiexer ,
It should be possible to disable this directly through EF Core:
context.Database.AutoSavepointsEnabled = false;
As for your issue, is one of the "destination table" or the "working temporary table" that is memory optimized?
Hello @JonathanMagnan
Yes we solved it by adding AutoSavePointsEnabled = false to our code. Yes, we have in our dbcontext a destination table which is a memory optimized table because of the load it generates