@ajcvickers once this is merged, can you please add a redirect from https://aka.ms/efcore-docs-sqlserver-save-changes-and-triggers to https://docs.microsoft.com/en-us/ef/core/providers/sql-server/misc#savechanges-and-database-triggers?

Could it be just HasTriggers() / HasTrigger() (inSQL Server there can be multiple)

The idea was for this to be the extension point for a future actual trigger API, which is why we didn't want an API that was only usable to declare that some trigger(s) are present. But FWIW I agree it's a bit odd.

@roji @ErikEJ I think we should re-discuss this. It's weird having to specify a meaningless name, and I don't really see the issue with "an API that was only usable to declare that some trigger(s) are present."

Well, I guess it should not "only be usable for that", but being "usable for that" seems fine.

@ajcvickers note that there are some other (relatively exotic) edge cases where OUTPUT (without INTO) isn't allowed, which have nothing to do with triggers. At some point I proposed another SQL Server-specific metadata API which would directly tell EF to avoid OUTPUT without INTO (UseUniversalUpdateTechnique?), and which a future HasTrigger API would turn on by convention; but we decided against this in design. We can revisit.