Нашел советы по коныертации данных из VFP DBF to MySQL (прошу извинить за английский и я не знаю кто истинный автор):

Let's try to figure out some rules:

1. MySQL doesn't support the Logical DataType. You should convert it to Numeric before the import.
2. The indexes are different from those under Visual FoxPro. For example, the expression 'first_name'+'last_name' cannot be used under MySQL. It should be 'first_name,last_name'. As you can see, under MySQL is possible to use in index expression belonging to different datatype, like follows: 'first_name,last_name,date_of_birth,security_number'. It work perfectly.
3. Under MySQL extensive use of indexes is disrecommended (unlike Visual FoxPro). The index should exist only you want very often a small set of data (under 25% from total).
4. Another issue is the sintax conversion. For example, I use indexes like this one: 'INDEX ON ALLTRIM(last_name) TAG name', to avoid the situation when the user place a Space before the name, forcing it to be the first one in the index. Unfortynatelly, MySQL doesn't support the ALLTRIM function. It has another one, named TRIM. As you can see, it is necessary a conversion of the Visual FoxPro functions to MySQL functions. Some of them are not supported, others have another name. Tough problem.
5. You have to be aware that the Memo and General datatype doesn't have an direct equivalent under MySQL. The closest equivalent is TEXT for Memo and BLOB for general. But both have three varians: TINYTEXT (2^8 chars), MEDIUMTEXT (2^16 chars) and LONGTEXT (2^32 chars). The same rule applies to BLOB. You should chose what to use.
6. The concept of a 'free table' is not supported under MySQL. Before importing a table, you should create a database, then create a table. For this reason, you can import an entire Visual FoxPro database, but the stored procedures are not supported and the relational integrity are not supported, too. Anyway, I was able to import a database into MySQL, and I am sure you can too.
7. Another big problem is the parameterized view. By default, the ODBC driver tries to optimize the width of the column, so, if the first result of an view is 'MIKE' and the second should be 'GRIGORE', the REQUERY function fails. It is necessary to check the checkbox 'Don't optimize column width' under ODBC in Control Panel. I've gone crazy about this, and Erik Moore enlightened me. Thanks again, Erik! (if you read this... :)
8. Again, about the views: It seems to be an ODBC driver problem, but if you create a remote view from a table in MySQL, the ODBC driver don't give the necessary information, such column widths. As result, you'll be forced to set the width of fields manually. And if after you alter the MySQL table, you'll be forced to set again the width of each field of the view which have worked. This is very frustrating, and I strongly suggest to build a app for this goal.