Hi SF Team,

For all datetime data fields I have set up in the BOMapper "Return Alternate on Null/Set Null...." and NULL Replacement Value = #1/1/1900# (for smalldatetime data type)

Therefore as I understand this feature, when the field value is NULL when saving the record, it writes a NULL value back to the database and not 1/1/1900.

However, the BO object is writing 1/1/1900 back to the database and not the NULL value. 

What I found when stepping through the BO logic using the debugger that if I don't set the value of the BO field to #1/1/1900# then the Set property within the BO code is never executed.  Therefore, when saving the record, the Get property logic retrieves the 1/1/1900 value of the BO.field and writes it to the database.

So what I have to do is in the BO_BeforeSave event I have placed the following code:

if BO.DateTimeFieldName = #1/1/1900# then BO.DateTimeFieldName = #1/1/1900#

This piece of code forces the Set property of the field in the BO to execute.  Now when the BO writes the value to the database, the Get property logic returns the NULL value and writes the NULL value back to the database.

This seems like a bug to me or am I doing something wrong in the BO Mapper configuration?

Thanks!

I did not have the AllowNullValuesOnNewRow set to True if that is what you meant by me experiencing some problems.  I have never used that property.  However, I did not initialize the Null fields with DBNull in the SetDefaultValues.   At one point, I was trying to use the code in the SetDefaultValues event  "BO.FieldName = DBNull.Value" which generated an error while in the IDE.  I did not think of using the Me.CurrentRow property to get this done.   Now everything works correctly, as long as, I have the Null fields setup properly in the BO Mapper using the "Set Null on Alternate" property (Text fields = String.Empty and Date fields = #1/1/1900#).  

In essence, as I stated in the first thread, I was doing this by forcing the Set property event to fired by placing logic in the BeforeSave event of the BO.  

Your way is a much cleaner way of ensuring NULLs are written back to the database for Add/Edit functions. 

I hope I finally understand how to handle fields in the database allowing nulls using SF BOs.

Thanks Ben for the clarification!

No problem

Glad you got it working.