Microsoft Access as a front-end to MySQL

[#1]

Both Access and MySQL support this, but is it allowable on Hostopia CGI given that port 3306 must presumably be exposed to the Internet and not just to PHP programs?

[#2]

I can connect using MySQL Administrator on the same port so I don't envisage it will cause a problem.

[#3]

Tnx Bob.
I am probably harking back to The Olde Days when (as I remember it):
-  3306 was fully blocked (for access via the Internet) on PAYH
-  3306 was blocked for access to the CCGI platform except from PN IP addresses
The first was a bit draconian and widely complained about on PUG.
The second was (I think) part of PN's security protecting the active pages of a site (FTP uploads etc were also blocked).     

[#4]

My attempt to link Access to Hostopia MySQL using the current Windows 7 ODBC 64-bit driver (version 5.3 UNICODE) failed when setting up the System DSN link details with:
Connection failed. [MySQL][ODBC 5.3(w) driver] Connection using old (pre-4.1.1) authentication protocol refused (client option ‘secure auth’ enabled):
MySQL Admin says that the server’s ‘Secure_auth’ is OFF, but it unclear how I can also switch it off on the ODBC driver (a bit of Googling says that the account causing problems is configured with an older password hash). I cannot of course switch it ON on the server...
Or should I reset my MySQL password and hope that it then has an acceptable (longer) hash  -  which seems odd since it was presumably only set up in 2014

Has anyone else run into this?

[#5]

I thought that the shorter password hashes were not supported on the MySQL 5.x version on Hostopia. Sorry to ask the obvious but you are attempting to connecting to the correct server sql5c51a.megasqlservers.eu ?

[#6]

Yes - sql5c51a.megasqlservers.eu
I have never had any trouble connecting to various tables in the MySQL database when calling from PHP, but if I use exactly the same username, password and database-name in Windows' ODBC System DSN driver setup page, clicking Test responds with the error message given in my previous post. The MySQL documentation has a good description of 'hash-length vs version' in http://dev.mysql.com/doc/refman/5.0/en/password-hashing.html and Google has plenty of info about the underlying problem, but in the ODBC setup page there is no Secure_auth parameter to change. Like you, I would have thought that Hostopia's V5 MySQL would not just have defaulted to 'long hash' but that this default would not have been changed.
At the server end, MySQL 5.6.5 and later have secure_auth enabled by default but earlier versions have it disabled by default.
At the client end, there is an equivalent parameter  --secure-auth which is enabled by default in 5.6.7 and later and disabled in earlier versions. If the client enables --secure-auth, it stops connections being enabled to accounts that use short (i.e. pre-4.1) password hashing.
It appears to be this combination of settings:  secure_auth disabled at the server but secure_auth enabled at the ODBC client end  - which causes the problem. Why? - because I am assuming that a client with --secure-auth enabled encountering a server with secure_auth disabled says to itself that the server may be accepting both sorts of hash (old small and new long), is thus insecure, and should not be connected to.