Blog Stats
  • Posts - 23
  • Articles - 0
  • Comments - 15
  • Trackbacks - 0

 

Friday, April 1, 2011

Row not found or changed


I have a .Net 4.0 site that uses Entity Framework and Linq to SQL. After reworking a few tables and a few page operations, a new error appeared: "Row not found or changed". Every time I commit changes to a particular table, this error would be raised. From a quick review of msdn and the internet, the primary reason for this exception appears to be data concurrency issues - (The source data in the database is out of sync with the data you are attempting to update.) That did not apply to my development environment, so I went to the web for more answers: http://social.msdn.microsoft.com/forums/en-US/linqprojectgeneral/thread/c672c8ee-bf2a-41b4-bb8b-aa76cc5d9b95/ Two posts stood out to me on this thread - - This might be caused by concurrency checks on data that is round-tripped to the client in hidden fields and then reconstituted on the server to be used as 'original' values during the update. Some data types may loose precision when converted to text and back. You can avoid this problem by turning on concurrency checks for this field in the mapping (a propety of the field/column in the designer.) - I have a feeling it might have something to do with a null<>string.empty conversion within the LinqDataSource control/viewstate. In my case, the original row had a null value in a nullable column. While handling the OnUpdating event to debug, it looked like it may have been stored as an empty string in the original object. I then compared the object directly with the data in the database - perfect match. But, it reminded me that the table which is now throwing errors had recently been modified in the dbml file. Time to check the structure of the table throwing the error. A new varchar field in the table was not marked as nullable in the dbml. This means to me that at some layer in the update process, null was being compared to empty string and .Net was unable to discern which row in the database was in need of an update. I wanted to believe that since the primary key on the table was defined in the dbml the remainder of the table definition should have no impact on resolution of the row being updated... But apparently not in the use case I was fighting...
 

 

Copyright © jkrebsbach