Randall,
you most likely need to change the date format in VFP before importing/exporting the data. Here is the procedure we use. You want to set it to the MySQL type just before the import/export and set it back to default right after.
One more thing, this is for the datetime data type. NOT the timestamp. Timestamp is a differnt data type in MySQL.
PROCEDURE jDateFormat
lParameter mTask
do Case
case mTask = 'MySQL'
set mark to '-'
set date to ymd
set hours to 24
case mTask = 'DEFAULT'
set mark to (xDateMkFmt)
set date to (xDateDtFmt)
set hours to (xDateHrFmt)
case mTask = 'AMERICAN'
set mark to '/'
set date to mdy
set hours to 12
otherwise
=MessageBox('Wrong Format Requested in jDateFormat().' + iLf ;
+ mTask, 48, ' Data Exchange')
endcase
RETURN
>Folks,
>
>This is a bit of a weird problem that we're having, and we'd really
>appreciate some help.
>
>We're using Navicat ver. 7.2.5 Enterprise. This is a MySQL "front end" that
>allows us to manipulate MySQL databases, and it also imports dbf
>files into MySQL format. (I'm sure most of you are familiar with it.)
>
>Anywho, we have a dbf file that uses the datetime data type as a timestamp,
>and there is also a corresponding field in a MySQL table that
>uses the datetime data type of MySQL. While trying to import a dbf
>file into MySQL, the datetime field in the MySQL table becomes
>"0000-00-00 00:00:00," even though we know that the dbf file contains
>a valid datetime timestamp. Also, we've tried using Navicat on other
>tables with the same table structure, and the import works just fine.
>
>Bad table? VFP never complained about it. (Shrug.) Also, I've
>researched this using Google and the Usenet (google groups) and
>never found anything similar. In other words, I did RTFM, looked
>through the index, and found nada :).
>
>TIA,
>
>Randall
Beer is proof that God loves man, and wants him to be happy. - Benjamin Franklin
John J. Henn