Full Convert moves the data for you from VFP to SQL - that's what it's for - so there is no writing code to move the data. All you have to do is replace blank dates with nulls before moving.
You pretty much have to allow nulls for the empty dates, unless you want to replace them with {01/01/1800}. But you don't really need to worry about the nulls. The Microfour folks deal with huge datatables and have a lot of performance issues they tweak constantly so there may be some advantage to avoiding them altogether, but for most first time VFP to SF/SQL conversions I'd bet the nulls are not going to be an issue. If so, you can always massage the converted data on the sql side and then change the structure with DDT to close down future nulls.
If your data already has nulls in it, you don't really need to fill them with anything. Just make sure your DDT structure allows for nulls.
Basically the easiest path is to first import your VFP structure into DDT. In DDT make any changes you want to fieldnames, types etc. You can delete the change history in DDT since you are not going to be updating an existing SQL database.
Then write that DDT schema to your SQL database so now you have empty SQL structures that looks the way you want them for your SF/SQL app.
Now use FullConvert to move the data from VFP tables to SQL tables.
From that point on, only change the SQL structure through the DDT.
If you are going to setup any default values on the backend ( autoincrement integer pks for example ) do it through the DDT. I'd recommend at first using backend defaults only for those PKs. I think the rest (a date that defaults to today() etc ) is better handled in the BOs
Just make sure you save your Full Contact project so you can export to sql, play with it, and then export production data for real when you know you have the conversion the way you want it.
Default values :
Two things - the BOMapper handles what to do with null values, not inserting defaults in a new record. It is an issue of translating how the BO will get data from the back end. So if a date is null, what do i send to the control (#1/1/1800#) The control knows how to look at that and show and empty date in the control.
The "default" values of the BO is something like :
In a new record, the State with default to "NY", the EnteredDate with default to Now() etc.
That is handled in the EventHandlers region of the BO :
'''
''' Sets the default values for a new row
'''
'''
Private Sub PropCoverageBO_SetDefaultValues()
me.State = "NY"
me.EnteredDate = Now()
End Sub
The BO stuff is in the BO partial class that you don't manually edit for the strongly type field properties :
'''
''' This field was imported.
'''
BusinessFieldDisplayInEditor(), _
Description("This field was imported."), _
DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)> _
Public Property [EXPIREDATE]() As System.DateTime
Get
Dim loValue As Object
loValue = Me.CurrentRow.Item("EXPIREDATE")
If loValue Is DBNull.Value Then
Return #1/1/1800#
Else
Return CType(loValue, System.DateTime)
End If
End Get
Set(ByVal value As System.DateTime)
If value <> #1/1/1800# Then
Me.CurrentRow.Item("EXPIREDATE") = value
Else
Me.CurrentRow.Item("EXPIREDATE") = DBNull.Value
End If
End Set
End Property
Notice the null on the backend becomes a "date" the control knows to treat as empty, then if you leave it empty, it sends a null to the back end.