FL is a table, FLBackup is also a table, same record.
lets say I change FL some field values but I dont know what the field names are and I want to revert back to the original field values, even after a submitchanges has been done, as long as I keep FLBackup cached it can be done, which bascially keep the same PK and does an UPDATE

var cols = fl.GetType().GetProperties().Select(p =>
new
{
Prop = p,
Attr = (ColumnAttribute)p.GetCustomAttributes(typeof(ColumnAttribute), true)
.SingleOrDefault()
}).Where(p => p.Attr != null && !p.Attr.IsDbGenerated);

foreach (var col in cols)
{
col.Prop.SetValue(fl, col.Prop.GetValue(flbackup, null), null);
}
Result:
_gDBContext.GetChangeSet()
{Inserts: 0, Deletes: 0, Updates: 1}
Deletes: Count = 0
Inserts: Count = 0
Updates: Count = 1

Make sure to do db.Table.Single(query) only then update works.

if you do db.Table.First(query) and perform submitchange() then it will not update value. Below code works and being used in production

Database db = new Database();
Table t = db.Table.single(p=>p.Column == ColumnName )
t.ColumnNameValue = value;

db.submitchanges();

thats it.

It’s a trap to lure people away from real programming into M$ proprietary crap.

Stick to SQL and you can work on every platform, not just M$

“which is what is happening in Dinesh’s example code, above).”

should read as

“which is what is happening in Richard Bushnell’s example code, above).”

By default, Linq to Sql uses Optimistic Concurrency (aka. O.C.). Everyone knows that and we’re all not disputing that.

So _BY DEFINITION_ this means that we _cannot_ update our object UNLESS we know it’s the same version in the database – otherwise we need to throw an exception. That’s what O.C. is all about.

So -> Linq to Sql does this in two ways.
1) If you have a TIMESTAMP field in the table, then send that across the wire along with the Primary Key and make sure that the current object’s TIMESTAMP field (that is about to be updated) is the same as the DB’s.

-or-

2) No timestamp? then we need to check -each- field (which is what is happening in Dinesh’s example code, above).

So … maybe you don’t want O.C. then?! If you _want_ to make sure that the data you’re about to update IS not more recent that the version in the code, then yes .. u need O.C. Otherwise, don’t do Optimistic Concurrency and therefore all these hacks to get around it.

To not use O.C., make sure each field in the table that is being updated, the ‘Update Status’ field is set to NEVER. The default is Always … so switch it over to NEVER.

As is said, Christian Zangl has said it perfectly right, above.

Good Luck!

Somebody want to explain why an update would cause that error and how to correct it?

public object Insert(object item)
{
using (TransactionScope ts = new TransactionScope())
{
ITable itbl = DataContext.GetTable(item.GetType());
itbl.InsertOnSubmit(item);
itbl.Context.SubmitChanges();
ts.Complete();
}
return item;
}
public object Delete(object item)
{
using (TransactionScope ts = new TransactionScope())
{
ITable itbl = DataContext.GetTable(item.GetType());
itbl.DeleteOnSubmit(item);
itbl.Context.SubmitChanges();
ts.Complete();
}
return item;
}

public object Update(object item)
{
using (TransactionScope ts = new TransactionScope())
{
ITable itbl = DataContext.GetTable(item.GetType());
itbl.Attach(item);
itbl.Context.Refresh(RefreshMode.KeepCurrentValues, item);
itbl.Context.SubmitChanges();
ts.Complete();
}
return item;
}

DbContext.Pessoas.Attach(p2);
DbContext.Refresh(RefreshMode.KeepCurrentValues, p2);
DbContext.SubmitChanges();

It’s works.

Pessoa p2 = new Pessoa();
p2.Id = 1;
p2.Nome = “Teste” + DateTime.Now.ToString();

DbContext.Pessoas.Attach(p2);
DbContext.Refresh(RefreshMode.KeepCurrentValues, p2);
DbContext.SubmitChanges();

this thing does WORK

private Product UpdateSomething(Product product)
{
product.value = 99;
return product;
}

public void UpdateAll()
{
var list = (from product in DataContext.GetTable()
select UpdateSomething(product)).ToList();

DataContext.SubmitChanges();
}

We can also include a where clause to filter those products being updated

Pessoa p2 = new Pessoa();
p2.Id = 1;
p2.Nome = “Teste” + DateTime.Now.ToString();

DbContext.Pessoas.Attach(p2);
DbContext.Refresh(RefreshMode.KeepCurrentValues, p2);
DbContext.SubmitChanges();

this way, only chances are updated.

Can someone let me know whether its possible

if(val.recordId == 0){
db.GrandPrixValues.InsertOnSubmit(val);
}
db.SubmitChanges();

Thats working and way more easy!

var product = new Product();
product.ProductID = 1;
Products.Attach(product);
product.Name = “Richard’s product”;
SubmitChanges();

Changeset.Dump() is something that only works in LinqPad.

– The changeset is generated from the DataContext, but in LinqPad, you don’t reference the DataContext, because you are actually inside it.

- Dump() is a LinqPad method defined as an extension method on Object. It is LinqPad specific.

If you want more information about LinqPad, you can contact the authors at http://www.linqpad.net. When I contacted them, they were very helpful. I’m sure they’d let you know how it works.

HTH,
Richard

That looks interesting, but doesn’t it really do the same as doing a select before an update?

DbContext.Pessoas.Attach(p2);
DbContext.Refresh(RefreshMode.KeepCurrentValues, p2);
DbContext.SubmitChanges();

this way, only chances are updated.

Its not ideal, but its simple, can be called through the linq datacontext, doesn’t require a round trip, doesn’t result in SQL strings in code, and doesn’t require a clumsy hack where you are trying to build the object to update it.

http://perpetuumsoft.com/Product.aspx?lang=en&pid=55

I suppose It is worth to try!

update c in Customer
where c.CustomerID = 12
set c.Name = “Bob WeHadaBabyItsABoy”