Encountered the same error using EF Core 7.X

I had a trigger on a table and upon insert an error was returned.

The target table 'MyTable' of the DML statement cannot have any enabled 
triggers if the statement contains an OUTPUT clause without INTO clause

If I gutted the trigger with no logic I still received the error. Disabling the trigger resolved the error. But, if I performed a manual insert, no error was returned from SSMS.

Solution for me, (Let the DBContext entity object know that a trigger is on the table).

Update Fluent API to …

builder.Entity<MyTable>(entry =>
    {
       entry.ToTable("MyTable", tb => tb.HasTrigger("MyTable_Insert"));
    });

More information can be found at the
Microsoft site pertaining to this topic Breaking changes in EF Core 7.0 (EF7)

My issue was similar – also regarding a breaking change in EF Core 7.X but I followed an alternative route, also present in the docs, since all of my tables have triggers…

As stated in Microsoft docs, in the Mitigation section, the below should help:

If most or all of your tables have triggers, you can opt out of using the newer, efficient technique for all your model’s tables by
using the following model building convention:

public class BlankTriggerAddingConvention : IModelFinalizingConvention
{
    public virtual void ProcessModelFinalizing(
        IConventionModelBuilder modelBuilder,
        IConventionContext<IConventionModelBuilder> context)
    {
        foreach (var entityType in modelBuilder.Metadata.GetEntityTypes())
        {
            var table = StoreObjectIdentifier.Create(entityType, StoreObjectType.Table);
            if (table != null
                && entityType.GetDeclaredTriggers().All(t => t.GetDatabaseName(table.Value) == null))
            {
                entityType.Builder.HasTrigger(table.Value.Name + "_Trigger");
            }

            foreach (var fragment in entityType.GetMappingFragments(StoreObjectType.Table))
            {
                if (entityType.GetDeclaredTriggers().All(t => t.GetDatabaseName(fragment.StoreObject) == null))
                {
                    entityType.Builder.HasTrigger(fragment.StoreObject.Name + "_Trigger");
                }
            }
        }
    }
}

Use the convention on your DbContext by overriding ConfigureConventions:

protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder)
{
    configurationBuilder.Conventions.Add(_ => new BlankTriggerAddingConvention());
}

It’s an obscure edge case, but I found myself here because I was seeing this error using Microsoft.EntityFrameworkCore.SqlServer 7.0.0-preview.

When I reverted to 6.0.8, the bug went away.

Serves me right for developing against a preview edition.

I have found the issue, and it is related to an extension package that we are using called ZEntity.BulkOperations.Extension. David Browne’s comments made me log the error and an inner exception pointed to the ZEntity BulkInsert as the error. I then discovered this link https://github.com/zzzprojects/EntityFramework-Extensions/issues/334 , which pointed out that this package DID handle triggers. All I had to do was to stop and restart the services using the db and the package, so that the newly added trigger would be discovered by ZEntity.

TLDR; I just had to stop and start the services to make the ZEntity package aware of the added trigger.

Thank you to all who answered!

For those now targeting Entity Framework Core 8 they have now implemented the ability to use or not use the “OUTPUT” clause on a table by table basis.

From the Microsoft Docs

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Blog>()
        .ToTable(tb => tb.UseSqlOutputClause(false));
}