Every time I re-do my dev machine I ultimately get “ERROR 2006″ once I try to import a SQL dump that is too big. It’s a simple fix. You just have to modify your my.ini config file located in the Data directory for MySQL. The default directory is  C:\Program Files\MySQL\MySQL Server 5.5
(or etc/my.cnf on linux)
Then just make a quick change (or addition)

max_allowed_packet = 64M

Restart your MySQL server Service and Bob’s your Uncle! Depending on how you installed MySQL, this value may already have been set to 1M, or it may be missing all together, so don’t hesitate in adding the setting should it be missing.

I really hate looking (or being) stupid. Nevertheless it happens from time to time. Most (if not all) times they are avoidable events. Had my observation of what the MySQL command line response was trying to tell me been a little better, perhaps my Google searching Kung-Fu failure would not have added additional salt to the wound.

When attempting to import data from a SQL dump I was getting the following error(s):

ERROR 1045 (28000): Access denied for user ‘root’@'localhost’ (using password: YES)

or

mysql: unknown option

As it turned out, it was a simple matter of syntax minutia I was overlooking.  Since Google couldn’t help me save myself, I’m hoping that I can list a few of the deviations of syntax for importing a dump file and it will help somebody whom comes across it to save a little face.

RIGHT:
mysql -uroot -ppassword test < test.dmp
mysql -uroot –password=password test < test.dmp
mysql –user=root –password=password test < test.dmp
mysql -uroot –password=password test < test.dmp

WRONG:
mysql -uroot -password=password test < test.dmp
mysql -uroot –ppassword test < test.dmp
mysql –uroot -password=password test < test.dmp
mysql -user=root –password=password test < test.dmp

May the Computer gods (Google?) shine upon those of you having a dashes dilema with MySQL dump files and bring you here for salvation.  :-)

I took it upon myself to be a good boy developer and get php unit tests working on my Windows 7 box.  To get PHPUnit working properly with my XAMPP install, I found an excellent tutorial here: (@ Courtney Robinson’s log)

It was pure gold, though I encountered the following caveats at step 5:

As Courtney states could happen, PhpDocumentor was already installed with pear, so I had to:

pear uninstall  PhpDocumentor

But then when I went to install it again I received “ERROR: unable to unpack <install-path>\PhpDocumentor-1.4.3.tgz”. I scoured the net for a bit, and found the required action to be:

pear upgrade pear (Mine was up to date however)
pear upgrade Console_Getopt
pear upgrade Structures_Graph
pear install PhpDocumentor

Then I was back in business and able to finish step 6 in Courtney’s tutorial.

P.s. If you don’t see the PHP tab when you go to Tools->Options (as mentioned in step 6)  you likely have the full install of NetBeans 7 but have not opened or created a PHP project yet.  You will need to click File-> New Project, pick PHP, click Next; then you can click Cancel.  This will initialize the PHP references in Netbeans and provide the PHP context tab when viewing the Options screen.

It had been a while since I last had to install XAMPP from scratch, create my databases, and reconnect my CodeIgniter apps to my DB On my local Windows machine.  So when I set everything up, I was surprised when I could no longer connect to my database.

The issue turned out to be a relatively simple solution.  When creating the database, using phpMyAdmin, I had created the database with the default “Any host”:

What the connection requires is for the Host be changed to localhost (If you have already created the Database, this can be changed under the Privileges tab):

You can also get around this by leaving the user you created with the Host of Any host, and then create a second identical user that has Local as the Host (You would do this so both localhost and other computers can use your computer as the Database Server).  A more detailed example of user creation for both localhost and %; go to this MySQL page: http://dev.mysql.com/doc/refman/5.0/en/adding-users.html

Thanks to the CodeIgnitor forums for helping me on this one :
http://codeigniter.com/forums/viewthread/190254/

I had 2 problems when installing XAMPP 1.7.4 on my most recently built computer (Windows 7 64bit Professional… they state 64 bit is not supported, though I suspect it installs in 32 bit compatibility mode just fine):

1: The pesky “XAMPP Component Status Check failure [3]” error.  Although the solution was simple, I feel dirty for using it as it is clearly an issue that should be addressed in the installer rather than hacking the registry to make the error message go away: <Oliver Baty’s post>

I installed XAMPP (right-click -> Run as administrator) to D:\XAMPP because the documentation suggests to install XAMPP off a root drive (apparently they only mean C:\ however).  Subsequently, as Oliver’s post states, I had to change the [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\xampp] -> Install_Dir registry setting from D:\xampp to C:\xampp.  Adios error message!

The second issue was significantly harder to track down, so I thought I would post all the variations of the same issue that I came across in hopes that it saves the hours of your life wasted googleing as I have had to:

The Problem
2: When in the XAMPP control panel, clicking Start for apache would provide the message “Apache started [Port 80]“, but apache would not really start. (This also originally showed itself as an error during install, stating “Ports 80 or 443 (SSL) already in use! Installing Apache2.2 service failed”)

The root cause was that Port 80 was being used by another process.  To get a list of “listening” processes, you can run the following at the cmd line:

netstat -oan

The important line in the output being:

   TCP    0.0.0.0:80             0.0.0.0:0              LISTENING       4

This told me that PID 4 was hogging up port 80, which was not allowing Apache to use it.  The resulting hours of searching and screaming told me that one of the following possible processes were using port 80 under the guise of PID 4, which is the “NT Kernel & System” System process.:

exhibit A: Under the services panel, find the service that has the description of “world wide web publishing service” and stop the service.  If you found this service, you can check to see if port 80 is still being used by running the netstat command quoted above.  If that doesn’t work, or you didn’t find it, go on to exhibit B.

exhibit B: Again, under services, search for “SQL server reporting services”, and if you find the service, stop it. Check to see if port 80 is still being used by running the netstat command quoted above.  If that doesn’t work, or you didn’t find it, go on to exhibit C.

exhibit C: Again, under services, search for “Web Deployment Agent Service”(MsDepSvc). If you find the service, stop it. Check to see if port 80 is still being used by running the netstat command quoted above.  If that doesn’t work… then it might not be the NT Kernel & System Process (The PID is usually 4 for this)

exhibit D: SKYPE! The PID could be any variety of numbers if Skype is the issue. I would suggest that you disable Disable Skype from starting when windows starts(in Skype this is under Tools->Options->General settings)  After all, you are a developer, why would you need to speak to another human?  You can kick Skype off of port 80 simply by “Quitting” the application.  Skype will still work and simply pick another port the next time you start it.  You might want to set Apache to start as a service when windows starts so Skype doesn’t cause your Apache not to start the next time you forget to close it before you fire Apache up.

C solved it for me… until I restarted my machine and then D was the issue.  Hopefully one of those variations solves it for you!

Please feel free to leave comments relating to this issue and I will update the post accordingly.  Together we can save the lives of countless developers, one google search at a time.