Paulo Reichert

I have an intermitent problem with Linq in Visual Studio "Orcas" beta 1. I have the following piece of code:

Trade editTrade = (from t in _db.Trades

where t.Serial == serial

select t).FirstOrDefault();

if (editTrade != null)

{

editTrade.DateChecked = DateTime.Now;

editTrade.CheckedBy = GetUserName();

_db.SubmitChanges();

}

Depending on the record I will get a System.Data.Linq.ChangeConflictException stating that the row changed or didn't exist. I can't see anything hapenning in the database (I have SQL Profiler running a trace). When it does the update successfully I can see the update statement being executed against the database.

I'm sure I have only one connection to that database and that code is the only one updating the record. Also I have checked that the query expression I use to get the record returns the correct values.

Can anyone tell me what I'm missing here Thanks a lot for any help.



Re: LINQ Project General ChangeConflictException when updating row

Matt Warren - MSFT

The ChangeConflicts collection on the DataContext can provide you with all the information for why the DataContext thought the row had been modified. You can track down the problem by catching the exception and writing out all the member's in conflict and their current, original and database values.






Re: LINQ Project General ChangeConflictException when updating row

Paulo Reichert

I have inspected the exception, but it hasn't got anything that actually helps me. I don't know what values it's supposed to have. If the reference to the exception is named xcp I get the following:

xcp.Data.Count = 0
xcp.InnerException = null
xcp.Message: "Row not found or changed."
xcp.Source: "System.Data.Linq"
xcp.StackTrace: "
at System.Data.Linq.ChangeProcessor.SubmitChanges(ConflictMode failureMode)
at System.Data.Linq.DataContext.SubmitChanges(ConflictMode failureMode)
at System.Data.Linq.DataContext.SubmitChanges()
at ItFx.DealCapture.DataAccess.TradeDataAccess.CheckTrade(String serial)"
xcp.TargetSite: {Void SubmitChanges(System.Data.Linq.ConflictMode)}

In _db (my DataContext object) in the ChangeConflicts collection I get the following:

_db.ChangeConflicts.Count = 1
_db.ChangeConflicts[0].IsResolved = false
_db.ChangeConflicts[0].MemberConflicts.Count = 0
_db.ChangeConflicts[0].Table
{Table(dbo.TRADE)}
[System.Data.Linq.Table<MyDomain.Trade>]: {Table(dbo.TRADE)}
Context: {MyDomain.DcsDatabaseDataContext}
Name: "dbo.TRADE"
RowType: {Name = "Trade" FullName = "MyDomain.Trade"}


There isn't anything else in either object that can help me... What should I be looking for





Re: LINQ Project General ChangeConflictException when updating row

Matt Warren - MSFT

MemberConflicts.Count is 0 so as far as LINQ to SQL is aware there are no actual conflicts. LINQ to SQL raises the exception when the UPDATE command succeeds but the server claims 0 rows were updated.

Can you paste here or send me the log of the UPDATE command being sent






Re: LINQ Project General ChangeConflictException when updating row

Paulo Reichert

Hi there,

Following your reply I investigated the update statement that it's sending to the database. What I have noticed is that there is one field in my table that is declared as follows:

[RATE] [numeric](20, 7) NOT NULL

In the Linq DBML file in my solution it has the following property values:

Server Data Type: Decimal(0,0) NOT NULL
Type: decimal (System.Decimal)

What happens then is that when the update gets sent to the database, the value passed in has 4 decimal places, whereas in the database the value has 7. That's what's breaking the update query. If I alter the update statement manually to the correct the trade value then it all works on the database side.





Re: LINQ Project General ChangeConflictException when updating row

Matt Warren - MSFT

Okay, that was probably a bug in the designer or SqlMetal.




Re: LINQ Project General ChangeConflictException when updating row

Paulo Reichert

Should I log this somewhere (connect.microsoft.com perhaps) Is there any workaround that I can use right now I have excluded that one field from the optimistic check for now, but would be nice if I could get it to work somehow.