PacManDude

Using Orcas with the latest DLINQ assemblies (v2.xxxx)

Scenario:

Added a record to the database using one datacontext, and i want to update this record using another DataContext, if i change the record BEFORE attaching it to the new datacontext, the SubmitChanges() will throw an exception of "Row not found or....".

is this the way it suppose to work this seems unreal that it'll try to match ALL fields of the existing pre ATTACHed record to the one ia m trying to Submit.

I also tried this:

put a breakpoint right before Attach, when the breakpoint hit, i changed one of the records fields in the database manually, and continue with debugging, i got the exact exception after calling SubmitChanges().

it realy seems that instead of matching to the PK only, it tries to match ALL fields value, and if ALL of them don't match, it throws an exception.

any ideas



Re: LINQ Project General Updating an existing record using Attach(..)

Matt Warren - MSFT

The DataContext uses Optimistic Concurrency, which means it will not take out locks on the database rows when you query for the data. The optimistic part is assuming that no one else changes the rows in the database. When SubmitChanges() is called the UPDATE and DELETE commands include an optimistic concurrency check in the WHERE clause which basically tests to see if the database row has been changed by some one else since the time you first read it. If it has been changed the UPDATE or DELETE fails. Upon failure, you can catch the ChangeConflictException and attempt to resolve the conflicts yourself and then submit the changes again.

Q: Why does it use all the fields and not just the primary key

A: The check is not used to find the row but the verify that it has not been changed.

Q: But why all the rows

A: You can adjust the check by setting the UpdateCheck propery for each column in mapping. By default all columns except large text/binary columns are checked. If the database has a 'version/timestamp' field that only that field is used.






Re: LINQ Project General Updating an existing record using Attach(..)

PacManDude

So, what is the use of Attach method when being used in multiple connections.

Do I need to make sure that noone changed the database record between the time i added it to the database and the next time i try to update it

this doesn't seem right, is there any way around it

i read somewhere that Attach takes 2 parameters (oldVersion,newVersion) and it compares the 2 for you, what ever happened to this method

Thanks in advance.





Re: LINQ Project General Updating an existing record using Attach(..)

Matt Warren - MSFT

The method you are referring to is new and will appear in Beta 2.

When you attach an object to a DataContext you tell the DataContext both the original state of the object (what you believe to be the existing state in the database) and your current state of the object. This is true for all forms of attach. They only differ on how you tell the DataContext about your changes.

When you submit changes, the DataContext checks the actual state of the database for you and alerts you when there is a difference. The idea is that this rarely occurs. However, you will need to account for the possibilty.

There are different strategies for this. If you where simply doing an operation against a single DataContext, you could just abort and start over with a new DataContext. This strategy is the simplest and works well for small transactional changes.

Another one is to actually inspect what failed. You may have a reason for doing this. Depending on the circumstance, you may want to overwrite the other change, give up on yours or simply merge the two together. All the information about the conflict is available through the DataContext API. Of course, this might lead to a lot of trick logic everwhere you call SubmitChanges. One thing you can do is instead of adding this code everywhere you submit changes you can simply override the SubmitChanges method itself to supply the logic once. Or better yet, you can communicate the conflict back to the user via the UI and let them decide what to do.