I've looked into this a lot more. I'm thinking that there is a "bug" in the BuildFieldCollisions method in DataLayer, in that it can't handle NULLs (at least for dates).



There are definitely situations were the best choice is to have a NULL value in the database for a date. This means the date hasn't been set. I have a deliverables table with a delivery date. Until the deliverable is actually delivered, there should be NO delivery date. It should be NULL. Also, a reporting tool will be used to report on this table. The users can build their own reports. This means that either:



- I have to train users to use 1/1/1800 if they want a date that isn't set

- I have to somehow embedd this in the reporting tool, which means if it ever changes, I have to remember to change it in two places.



So, I really think BuildFieldCollisions should be able, some how, to handle NULLs.



BTW, I found the RetrieveConcurrencyRowHandler property on BusinessLayer and this can be used to massage the server row so there are no nulls, but I don't see any way to fix the current, local row, without ending up actually saving my alternate value into the db. Maybe I'm missing something....



Finally, I'm starting to think that the issue with the custom field property is some weirdness on one of my tester/users machines. The custom field should never be checked (as near as I can tell) based on the code (it uses the server row, which normally won't include any additional custom rows). However, I'd really like confirmation on this or any other concurrency issues I might need to deal with when using custom fields.



Thanks!

Bump...this is kind of urgent, any help would be appreciated! Thanks!

More info. The type conversion exception occurs if server value is NULL and the local value isn't. It occurs in the BuildFieldCollisions method.

This is likely because I don't fully understand how the concurrency handler works, but I'm having trouble with two issues related to concurrency:



1. I have a table that has several date fields in it. These fields can all be NULL, because the dates can be NOT set. I have a SetDefaultValues handlers that provides my NULL replacement date for them. All is fine...until I have a concurrency conflict (I'm using row version concurrency). If one of the conflicting fields is a date and one of the values of that field is NULL, I get a type conversion error. How do I handle NULLs in this case?



2. Same form (hitting same table) also has a couple of custom properties defined. These properties get their data from some extra columns that might be available when the BO is filled. I check if the column exists before attempting to get the value and if the data table doesn't have the column, I return a default. This works great. However, with concurrency again, when there is a conflict, I'm getting an error that one of these custom fields isn't in "Table1" (default table name of a table in a data set I assume). Apparently, the concurrency handler is accessing this custom field, but not using my custom getter, somehow going directly to the data table. Any ideas on how to handle this better ( er...at all)?



I'm trying to release this into production, so this is fairly urgent!



Thanks!