title: How to DELETE without ON DELETE CASCADE (conflict REFERENCE constraint)
body: <p>I have a gigantic legacy database with a table that has multiple foreign keys pointing to one other table and with not a single cascade in sight, similar to sample tables below:</p>
  
  <pre><code>create table Users (
      Id int primary key identity,
      Name varchar(max)
  )
  
  create table Products (
      Id int primary key identity,
      Name varchar(max),
      CreatedBy int foreign key references Users(Id),
      UpdatedBy int foreign key references Users(Id)
  )
  
  insert into Users values('Bar')
  insert into Users values('Baz')
  insert into Products values('Foo', 1, 2)
  </code></pre>
  
  <p>I need to be able to to delete some of the old data, but it of course throws reference exceptions:</p>
  
  <pre><code>delete from Users where Name='Bar'
  </code></pre>
  
  <blockquote>
    <p>The DELETE statement conflicted with the REFERENCE constraint "FK__Products__Create__1AD3FDA4". The conflict occurred in database "Foo", table "dbo.Products", column 'CreatedBy'.</p>
  </blockquote>
  
  <hr>
  
  <p>Due to the sheer complexity of the database I can't predelete all of the references, so I'm trying to add temporary foreign keys programmatically with cascades set to resolve them. However, for this particular table that has multiple foreign keys to one other table, this results in <code>cycles or multiple cascade paths</code> on the second <code>UpdatedBy</code> alter:</p>
  
  <pre><code>alter table Products add foreign key (CreatedBy) references Users(Id) on delete cascade
  alter table Products add foreign key (UpdatedBy) references Users(Id) on delete cascade
  </code></pre>
  
  <blockquote>
    <p>Introducing FOREIGN KEY constraint 'FK__Products__Update__1DB06A4F' on table 'Products' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.</p>
  </blockquote>
  
  <hr>
  
  <p>How can I make <code>delete from Users where</code> work while maintaining referential integrity, either by somehow getting around multiple cascade path issues or otherwise?</p>