title: Foreign Keys become untrusted after EF inserts/updates
body: <p>We have an ASP.NET Web Application that uses EntityFramework code first to perform inserts/updates and for at least some of our database's foreign keys, they become untrusted any time that we insert rows using EF. </p>
  
  <p>Important notes:</p>
  
  <ul>
  <li>None of the foreign keys are marked as not for replication</li>
  <li>Constraints are not being explicitly disabled and then re-enabled and I'm aware that if we were disabling and re-enabling that I would need to do "WITH CHECK CHECK CONSTRAINT all" </li>
  <li><del>We are not doing bulk inserts when this occurs</del></li>
  </ul>
  
  <p>I've tried running sql profiler to see if anything strange was going on and I didn't see anything. I looked to see if EF was doing any "MERGE" statements because I found something which stated that those statements could leave constraints untrusted. It's my understanding that without some workarounds, EF won't do any "MERGE" statements anyhow. The only thing that I can think of that is different from the default setup is that snapshot isolation is turned on but I haven't found anything that says this would have an effect on trust of FKs.</p>
  
  <p>Edit: Just want to add that I have run the SQL statements to re-trust the FKs and then run a sequence in the web application that brings the same FKs right back to being untrusted. It's repeatable.</p>
  
  <p>What else could be causing it or what else can I possibly try to determine why they are becoming untrusted?</p>
  
  <p>EDIT: Turns out deep in the call tree we were doing bulk inserts using EFUtilities library and this library by default does not enable or provide an override to enable constraint checking on the underlying SQLBulkCopy object. We have since forked and modified the EFUtilities (original project is pretty much dead on github) library to add a method overload for bassing in SqlBulkCopyOptions.</p>