I am not sure about TableAdapters, but the SqlCommandBuilder generates similar syntax, and in that case, IsNull_Emailwould reflectwhether the original value of the email field was null, not the new value. Have you checked the what the original value of the field is, according to the dataset (row["Email", DataRowVersion.Original])?

I have run into the same problem it seems that the @IsNull_Email is being set when ever the value is set. Because of this it makes the built in concurrency features useless for me. I think that when it auto generates the stored procedures the @IsNull_Email should not even need to be passed, instead it should look something like this

([@Origional_Email] IS NULL AND [Email] IS NULL) OR [Email] = [@Origional_Email]

If anyone knows a better way of doing this than going into the designer and removing a bunch of parameters from the update command and changing all the auto generated stored procedures please let me know but this is the only way i can figure out how to do it and still have the benifits of the built in concurrency.

Thanks in advance

We hit the same problem, where we're getting false concurrency errors when the original value of a field is null and it's updated to a new value.

The only thing we've found to fix this is to "set ansi_nulls off" in the procs that are generated by the adapter. If you're not using procs, I'm not sure what the fix would be.

Either way, I think the "@IsNull_ColumnName" approach is a strange way to handle null value optimistic concurrency checking, when Microsoft's own documentation recommends a "(@original_ColumnName is null AND [ColumnName] is null) OR (@original_ColumnName = [ColumnName])" approach (http://msdn2.microsoft.com/en-us/library/aa720364(VS.71).aspx ), which would work regardless of the ansi_null settings.

As to CommonGenius's note, in testing it appears that the @IsNull_ColumnName refers to the new value, not the original value, although certainly it would make more sense to be looking for null on the Original value in this case.

I'd like to see a proper response from the ADO.Net team on this.

If you have a relatively simple, reproducible case, you should submit a bug report on Microsoft Connect.

Submitted : https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=310592

I run into this very similar issue. Looking at the generated Update sql i would conclude the same as mentioned in the MS issue report. The "set ansi_nulls off" does work but this is not recommended by msdn and probl infects performance see link badly.

We found a solution in editing the DataAdapter properties of the UpdateCommand in the visual studio xsd editor. For the (sub) propertie 'parameters' with the name @IsNull_[columnname] set the SourceVersion to Original to Current. The @IsNull_[columnname] relates to the original value like described in the MS connect bug report. Then the Update/Delete command are correctly called by generated code.

Than it works with optemistic locking!! (Wished the people of MS connect pointed this feature out though ...)

Ciao!

I run into this very similar issue. Looking at the generated Update sql i would conclude the same as mentioned in the MS issue report. The "set ansi_nulls off" does work but this is not recommended by msdn and probl infects performance see link badly.

We found a solution in editing the DataAdapter properties of the UpdateCommand in the visual studio xsd editor. For the (sub) propertie 'parameters' with the name @IsNull_[columnname] set the SourceVersion to Original to Current. The @IsNull_[columnname] relates to the original value like described in the MS connect bug report. Then the Update/Delete command are correctly called by generated code.

Than it works with optemistic locking!! (Wished the people of MS connect pointed this feature out though ...)

Ciao!