Abby and Win’s Blog

For the past couple of days I’ve been trying to set up one of our XServe running Leopard Server at work for web hosting. I was able to configure the Web, AFP, and SMB properly. The problem I was having was configuring MySQL. It was easy to enable but trying to connect to it from other computers in the same domain was the problem. There’s a checkbox with “Allow network connections” in the Server Admin section of MySQL. So I checked it, save, and restarted it. I still wasn’t able to connect. I checked for firewall settings. I pinged the host and got a response. I couldn’t figure out what was wrong. So I googled it.

The common answer I found was to edit the /etc/mysql/my.cnf file. Well it’s not there but I did find a /etc/my.cnf file. So I tried editing that file and restarting. It didn’t work.

Then I remembered that the php.ini file that Leopard Server is using isn’t in the default location /etc/php.ini, but it ran the /private/etc/php.ini. So I looked in there and found another my.cnf file. I edited the file by adding # in front of skip-networking entry. I restarted it and it finally worked.

So here’s what you need to do:

• Go into Server Admin and check the Allow network connections and save
• Comment out the skip-networking entry from /private/etc/my.cnf
• Add the IP address of the computer you will be accessing MySQL remotely
• Give it the privileges it needs
• Restart MySQL

That should allow you to connect to MySQL running on Leopard Server remotely.

We recently installed OS X Leopard Server at work. I had to take MySQL databases from our old Tiger Server and restore them onto the new XServes. Both servers are running MySQL Server version 5.0.45 but our Tiger server is running MySQL Client version 5.0.22 while our Leopard servers are running MySQL Client version 5.1.18. According to MySQL’s documentation (http://dev.mysql.com/doc/refman/5.0/en/mysqldump.html):

Prior to release 5.0.48, this option did not create valid SQL if the database dump contained views. The recreation of views requires the creation and removal of temporary tables and this option suppressed the removal of those temporary tables. As a workaround, use --compress with the --add-drop-table option and then manually adjust the dump file.

I tried the –compress option but it didn’t work. I still had to manually adjust the SQL file. The I tried the GUI tool from MySQL, http://dev.mysql.com/downloads/gui-tools/5.0.html (MySQL Administrator).

Once you create the backup, you can restore it using the same application on the newer server. It will even include the views. Once you start using the newer client, you shouldn’t have a problem restoring databases with views from backups made with the mysqldump command.

I recently had to transfer over some databases from MSSQL Server 2000 to MySQL. Unfortunately, the date format that MSSQL keeps is MM-DD-YYYY HH:MM:SS am/pm. MySQL uses YYYY-MM-DD HH:MM:SS (24hour format). For example, 8/14/2007 5:00:00 PM (MSSQL format) and 2007-08-14 17:00:00 (MySQL format). In MySQL, we can use the date_format(). But what is the equivalent for MSSQL? That would be the CONVERT(). This is how you would use it.

Here’s the query to run on MSSQL:

SELECT CONVERT(VARCHAR(40),[date_column_name],120) AS new_date_format FROM [table_name]

The “new_date_format” is the column name that will display the MySQL formatted date. This should also work if you have a column that stores datestamp and a column that stores timestamp.

You can find a list of expression values from http://msdn2.microsoft.com/en-us/library/ms187928.aspx. Hope this helps somebody.