+1  A: 

I wonder if it wouldn't be better to use an "INSTEAD OF" trigger (delete) on the table... or just don't lie to LINQ: if you want to do an UPDATE (not a DELETE), then update the object (don't delete it). For example, write a method on the data-context that simulates delete, rather than using DeleteOnSubmit.

You may also be able to do something with overriding SubmitChanges and investigating the deltas, but I'm not sure it is a good idea

Marc Gravell
No, no, I am not lying to LINQ, just ..interpreting: in my domain model the "update" is a "delete". I came across the described problem when I used one of the database tables as a datasource for a plain datagridview, deleted a row in the grid and called the SubmitChanges-Method of the context. I want to make sure that any object can use the datacontext and do the "right thing" when deleting.
Stephan Keller
+1  A: 

The problem with doing it that way is, linq assumes that you are going to use the same CRUD operation that you are overriding. Take a look at this article (Responsibilities of the Developer In Overriding Default Behavior (LINQ to SQL))

This is what I would do:

partial void DeleteUnit(Unit instance)    
{        
   //instance.DLDAT = DateTime.Now;        
   //this.ExecuteDynamicUpdate(instance);

   PdpDataContext cx = new PdpDataContext();
   cx.ObjectTrackingEnabled = true;
   Unit u = new Unit();
   u = cx.Unit.Single(x => x.INTUNITNO == 1);
   u.DLDAT = DateTime.Now;
   cx.SubmitChanges();
}
Stephen B. Burris Jr.
Thanks, that worked fine.
Stephan Keller