Having just recently decided to start supporting MySQL, I went ahead and setup a new database server and installed MySQL 4.1.13, all seemed to be fine until I actually came to connect ColdFusion to a MySQL database, then Oops. I got an error something like this Connection verification failed for data source: mysql_bad
java.sql.SQLException: Communication failure during handshake.Is there a
server
running on localhost:3306?The root cause was that:
java.sql.SQLException:
Communication failure during handshake. Is there a
server running on
localhost:3306? After a fair bit of investigation I discovered that MySQL4.x has changed the way passwords are encrypted. So anything that is using the old method will not connect to your database. This includes the MySQL drivers that come with CFMX as they are 3.x drivers. You now have two options.

1. Set your MySQL server to use the old 3.x style passwords.
2. Install a newer MySQL JDBC driver.

I in fact chose to do both. You can in fact set the server to use new or old password globally and then set individual databases to use the opposite. I have set the MySQL to use old style passwords, as this appears to be the most common requirement, and if a client then has problems, I change their database to use the new style passwords. Set your MySQL Server to use old 3.x style passwords Open your my.ini file on your MySQL Server and find the [mysqld] section, now just add the parameter "old_passwords". You can now use the standard MySQL driver that comes with CFMX for your DSN. E.G. [mysqld]
# The TCP/IP Port the MySQL Server will listen on
port=3306
#Use old password encryption method
old_passwords Steps to install a new MySQL 4.x JDBC driver

• Download the MySQL Connector J JDBC driver
• Make the JDBC driver available to CFMX through the classpath by saving mysql-connector-java-3.0-bin.jar in either $CFMX_HOME/runtime/servers/lib/ for CFMX Server Configuration or $JRUN_HOME/servers/lib/ for CFMX on JRun Configuration. This makes the driver available to all JRun server instances.
• Restart CFMX server.

Adding a DSN using the new driver

• Add new datasource selecting "other" as the driver
• Add the JDBC URL jdbc:mysql://[server]:[port]/[database]
• Add the Driver Class com.mysql.jdbc.Driver
• Fill in the username/password, and adjust other dsn settings if needed.
• Submit datasource for verification
• As long as the DSN verifies, don't forget to remove the username and password, as you should be passing these in your code.

I am sure a lot of people have had this error, especially seeing as Macromedia released the following technote. http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_17834 But this technote does not solve the problem, it just provides a workaround and a pretty lame one at that. We had this problem ourselves yesterday after transplanting a hard disk into a new server, but I certainly did not want to set all sites to use LOW application protection, as this would result in a very unstable web server that would probably fall over a lot as it doesn't just host CF. And I knew there had to be a proper solution as all these sites worked fine previously on the old server. So I started looking further into the problem and discovered that ASP was having the exact same issue, so it was in fact nothing to do with ColdFusion at all, but rather a problem with IIS. In the system Event Logs, the following type of error was occurring repeatedly. The server failed to load application '/LM/W3SVC/4676/ROOT'. The error was 'No such interface supported A bit of Googling and I worked out this was related to a problem with component services. And low and behold when I tried to open component services I couldn't, getting the following error. Catalog error - An error occurred while processing the last operation: 80040154, Class not registered. So it seemed I needed to re-install component services. Instructions on how to do that can be found here :- http://support.microsoft.com/?id=301919 But still this did not solve my problem, it seemed the IIS packages were not installed. The following are required for IIS to operate properly.

• IIS In-Process Applications
• IIS Out-of-Process Pooled Applications
• IIS Utilities

After a bit more Googling, I found out how to add these packages. Perform the following steps.

1. Open command prompt, navigate to %windir%\system32\inetsrv folder, and enter rundll32 wamreg.dll, CreateIISPackage
2. then regsvr32 asptxn.dll
3. Now type IISRESET at command prompt to restart IIS services, then re-open Component Services MMC to verify the IIS packages are recreated.
4. Reboot server.
I now have everything working again as normal, and no sites had to be set to "LOW" application protection. This solution may not work for you as your problem may be slightly different, but hopefully it will give you an idea where to start Googling. But for god sake don't resort to the Macromedia workaround though.

A couple of months ago I installed CFMX7 with the great expectation on being able to use the new multiserver version with it's inbuilt instance manager to cut down on the amount of work required in the creation of the semi-dedicated hosting plans we provide over at CFMX Hosting. All seemed to be great, until I realised that security sandboxes didn't work at all in this type of installation. Further testing uncovered the fact that this was also true of CFMX6 as well. As has become an all to common occurrence of late, I had hit a problem that NO-ONE else seemed to have experience of, even the gurus. (NB: One of the problems with being a so-called GURU, who do you go to for help?) In this case I resorted to opening a support ticket with Macromedia as I considered this to be a bug. Annoyingly you have to give over your creditcard details to open a support incident, even if it's a bug, but thankfully you don't get charged if you prove the fault is Macromedia's :-) It turned out it does actually say in the CF docs somewhere that sandboxing will not work with J2EE installations, but even the MM support guy didn't know this and found out from someone else. Alas there was not also a working solution in the docs to get it working. It provided a workaround that was essentially useless as whenever you restarted the service it would revert to the old settings. Anyway it has been a long and painful process getting this working as I moved house in the middle of this process and was offline for 3 weeks. After much pissing about, numerous emails with MM support and eventually a breeze meeting I got it solved. MM did publish a tech-note on this after our discussion, but unfortunately they got it wrong. Hopefully they have since posted it with my corrections, which does include fixing the windows service to run the instance with the correct config settings. When I find the technote i'll post the link. Basically you have to add some entries into your jvm.config file to enable the sandbox security (and they are very picky about how you enter them), but this has certain repercutions. It can affect standard (non CF) jrun instances, so you need to really create custom jvm.config files for each instance and then edit your windows service to start the jrun server using this .config file. You will also need to modify all the paths in each new jvm.config, note that the original paths are "cfusion_ear", but in new instances they are "cfusion.ear", it took me ages to spot this difference, and the instance wont start if the paths are wrong.

IMPORTANT NOTE:

One other thing to consider is that you can only restart an instance that uses its own JVM.config via the windows service or via the jrun command passing the required attreibute. If you restart it via the CFADMIN instance manager or via the JRUN Management Console, it will be started using the default jvm.config. Update 29/04/2006: MM have finally posted a technote on this problem, its only taken a year. CLICK HERE