Thats nasty, but simple:
Check if the data types for all fields in the O/R-Designer match the data types in your SQL table.
Double check for nullable! A column should be either nullable in both the O/R-Designer and SQL, or not nullable in both.
For example, a NVARCHAR column “title” is marked as NULLable in your database, and contains the value NULL. Even though the column is marked as NOT NULLable in your O/R-Mapping, LINQ will load it successfully and set the column-String to null.
- Now you change something and call
SubmitChanges(). - LINQ will generate a SQL query
containing “WHERE What can I do to resolve a “Row not found or changed” Exception in LINQ to SQL on a SQL Server Compact Edition Database? IS NULL”, to make sure the title has not been changed by someone else. - LINQ looks up the properties of
What can I do to resolve a “Row not found or changed” Exception in LINQ to SQL on a SQL Server Compact Edition Database? in the mapping. - LINQ will find What can I do to resolve a “Row not found or changed” Exception in LINQ to SQL on a SQL Server Compact Edition Database? NOT NULLable.
- Since What can I do to resolve a “Row not found or changed” Exception in LINQ to SQL on a SQL Server Compact Edition Database? is NOT NULLable, by
logic it never could be NULL! - So, optimizing the query, LINQ
replaces it with “where 0 = 1”, the
SQL equivalent of “never”.
The same symptom will appear when the data types of a field does not match the data type in SQL, or if fields are missing, since LINQ will not be able to make sure the SQL data has not changed since reading the data.