Hmm... not sure about that.

I suspect it's due to how you've got change tracking configured. As
ever, set the log to write the SQL out where you can see it - that's
likely to give hints as to what's going on.

Without a timestamp column it issues a WHERE matching all the old values -
i.e. (from a simple PUBS example):

UPDATE [dbo].[Employees]
SET [Extension] = @p16
WHERE ([EmployeeID] = @p0) AND ([LastName] = @p1) AND ([FirstName] = @p2)
AND ([
Title] = @p3) AND ([TitleOfCourtesy] = @p4) AND ([BirthDate] = @p5) AND
([HireDa
te] = @p6) AND ([Address] = @p7) AND ([City] = @p8) AND ([Region] = @p9) AND
([P
ostalCode] = @p10) AND ([Country] = @p11) AND ([HomePhone] = @p12) AND
([Extensi
on] = @p13) AND ([ReportsTo] = @p14) AND ([PhotoPath] = @p15)

Without the necessary data, it somehow short-circuits to "0=1". I haven't
checked how it detects this.

I think you will struggle to UPDATE an object that you didn't get via LINQ.
You can probably do it if you try hard enough... but... why? Note that you
can serialize/deserialize to round-trip:

      Employee emp1;
       using (PubsDataContext ctx = new PubsDataContext())
       {
           ctx.Log = Console.Out;
           Employee emp0 = ctx.Employees
               .Where(x => x.EmployeeID == 1).Single();
           // make a seraialized clone
           DataContractSerializer dcs = new
DataContractSerializer(typeof(Employee));
           using(MemoryStream ms = new MemoryStream()) {
               dcs.WriteObject(ms, emp0);
               ms.Position = 0;
               emp1 = (Employee) dcs.ReadObject(ms);
           }
       }
       using (PubsDataContext ctx = new PubsDataContext())
       {
           ctx.Log = Console.Out;
           ctx.Employees.Attach(emp1);
           emp1.Extension = "2314";
           ctx.SubmitChanges();
       }