I'm having a problem where a DateTime field bound to a "virtual" column isn't working properly.  The virtual column is created using GetLocalBindingProperties and is included in the query.  Here's the query:

    Public Function GetProspect(ByVal ProspectID As Integer) As BusinessObjects.Prospect Implements IDataAccess.GetProspect
        Dim p As New BusinessObjects.ProspectQuery("p")
        Dim a As New BusinessObjects.AppointmentQuery("a")

        p.Select(p, a.StartDate.As("FollowUpDate"))
        p.LeftJoin(a).On(p.FollowUpAppointmentID = a.AppointmentID)
        p.Where(p.ProspectID.Equal(ProspectID))

        Dim Prospect As New BusinessObjects.Prospect
        Prospect.Load(p)

        Return Prospect
    End Function 

 And my code in my custom Prospect entity:

	Protected Overloads Overrides Function GetLocalBindingProperties() As List(Of EntitySpaces.Core.esPropertyDescriptor)
            Dim props As New List(Of EntitySpaces.Core.esPropertyDescriptor)

            props.Add(New EntitySpaces.Core.esPropertyDescriptor(Me, "FollowUpDate", GetType(DateTime)))

            Return props
        End Function

        Public Property FollowUpDate() As Nullable(Of DateTime)
            Get
                If Me.GetColumn("FollowUpDate") Is System.DBNull.Value Then
                    Return Nothing
                Else
                    Return CType(Me.GetColumn("FollowUpDate"), DateTime)
                End If
            End Get
            Set(ByVal value As Nullable(Of DateTime))
                Me.SetColumn("FollowUpDate", New Nullable(Of DateTime)(CDate(value)))
            End Set
        End Property

I set the binding up in design time and the weird part is the FollowUpDate field is returned and bound properly when the form is loaded.  If I change the value on the form (it's using DevExpress' DateEdit control), the property in my custom entity is updated perfectly fine.  When I called BindingSource.EndEdit right before I call Prospect.Save, the entity's data is reverted back to what it was when it was read from the database and my change is gone. 

I've researched the issue on the web and found references to issues binding to Nullable types when the binding is looking for a strict DateTime, not a DateTime?.  The recommended approach of ensuring a Format is specified for the binding didn't work for me.
 

While this is not the problem, just to clarify, you never call BeginEdit() on a BindingSource. The method does not even exist. You DO call EndEdit() on a BindingSource. In most cases, BindingSource calls EndEdit() for you as the user navigates the grid. The reason calling EndEdit() is recommended is for those instances where the user changes data, never navigates out of the column or row, and clicks save. In that case, the BindingSource does not call EndEdit() on the current row. You must call it explicitly.

"FollowUpDate" is a virtual column for Prospect. It is created from an aliased joined column. That is not to be confused with the hierarchical property:

prospect.AppointmentCollectionByFollowUpAppointmentID[0].StartDate

Virtual columns are not saved. Even if it comes from a Join, EntitySpaces does not automatically hook it up to the hierarchical property. That still needs to be done in code.

David,

I do in fact have code to handle the saving of FollowUpDate.  As you probably figured out from my earlier post, I'm storing an AppointmentID in the Prospect table which is where the date is actually stored.  As I started to create a simpler sample to see if I could reproduce the problem for you guys, I came across something else.  If I change another of the bound fields (non-virtual for that matter) and the FollowUpDate too, the entity is seen as being dirty and my custom save code works (i.e. FollowUpDate is saved properly).

This leads me to think one of two things: 1) it's got something to do with a Nullable DateTime field and some weird binding issue, or 2) since ES doesn't "save" virtual columns, they're not marking the entity as Dirty.

I'll test my theory this afternoon.  Thanks for the help thus far...