>ODBC has an old history of bad performance

Where have you seen this? Have you tested to make sure ODBC performance is not good enough for your application?

>and there is also the problem mentioned by Anatolly Mogytrvets.

That problem is an issue communicating with the machine that hosts the MySQL database. It sounds as though that ISP is only allowing port 80. If that's the case you'd have to use some hack such as Anatoliy outlined in order to process your data. You would have the same problem with OLEDB, Java connector, or any other connection technology if it used a port other than one allowed by the ISP.

>I was wondering if someone could code an API like FoxMySQL that was done in the past for FOXPRO 2.6 through FLL (FOX Connectivity Kit).
>But this fll runs only under WIN95/98 client. The limit is imposed by the winsock2.dll that is the base of the database connection. You can see the complete explanation on the URL http://natalie-tours.ru/my/fsox/.
>If such API can be coded using modern resources we can use VFP as a client no matter where the database is. I will connect my client through socket on a UNIX system. I am wondering if we can also use named pipe.

Well, if you want to go to the trouble of implementing some sort of custom sockets or named pipes interface to a remote RDBMS you're welcome to do so.

You can already use VFP as a client for any database that supports ODBC. Most do, on both Windows and UNIX-like OSs. You can also attach via OLEDB if the database supports it (MySQL may have an OLEDB driver) and the VFP8/9 CursorAdapter makes it easier to work with disparate data sources.

If a connection port is available it will be a lot easier to set up an ODBC connection than to write your own interface. If it's not available it's unlikely that your own custom interface using your own custom port will be available either.

I wouldn't even think of writing my own interface unless I had a proven, compelling need to do so. Why reinvent the wheel?