Magento Error SQLSTATE[28000] [1045] Access denied for user ‘username’@’localhost’ (using password: YES)

Magento Error SQLSTATE[28000] [1045] Access denied for user ‘username’@’localhost’ (using password: YES) magento help2 120x120I have fallen foul of this error a couple of times now and it is tricky to find the correct information online to fix the problem. It seems there are two obvious situations where this error occurs and depending on your version of Magento, or exactly what you did then there are three simple things to check to fix it and get your Magento site back up and running.

It is worth mentioning at this point that you can always get back to your system by renaming your local.xml file and hitting your homepage. This takes you to the install page. Simply replace the local.xml file with the correct credentials (see below) and rename it back again.

Incorrect database details

People often see an unexpected error message and immediately assume that something isn’t working properly but sometimes, just sometimes, the error message is actually telling you problem. Your database credentials are stored in the file app/etc/local.xml and the first thing to check is that the details in this file are correct. I can think of a few obvious reasons why these details could be wrong and it is always worth checking.

  1. A simple typo when entering the details
  2. Your hosting company or IT department have moved the database
  3. You have moved to a new hosting company or server
  4. You or another developer has uploaded the local.xml file from your test/dev server.

Check for use_cache.ser

I can’t verify this because I think it only happens in older versions of Magento, perhaps Magento 1.3 and earlier. Even though you have corrected your details in your local.xml file the details may still be cached in this file, so simply delete it.

Uploaded the local.xml file by accident

This is what gets me every time – I have a huge amount of changes to upload and I upload the whole app folder thus overwriting the local.xml and just as importantly the permissions on all of the folders.

The etc folder needs to be writable by the web server. Try setting appropriate permissions, and re-save or touch the local.xml from SSH.

That’s it, so far this has got me out of the situation without having to resort to creating a new database and migrating my data. If you have any luck with these methods, or find something else that works – or doesn’t work – then let me know!

Update:

No sooner than I had written all of this down and bam! my Magento site has the same problem again. I considered what is happening carefully. I had caused the problem by uploading my whole development app folder over the top of the live one – including the local.xml file and probably some permissions on folders. This caused the dev settings from the local.xml to end up in some kind of cached file/memory. Even though I corrected the local.xml the development settings kept cropping up and crashing the site. So clearing the local.xml file doesn’t reset the cache that stores the setting s for the same file.

Ok, so wait a minute – how does this ever happen. Assuming the site was originally working fine the correct settings from local.xml should be in some cache. How does an incorrect local.xml file being copied over clear this cache? Manually trying to correct the problem with a new local.xml file doesn’t do it, so what is actually causing the original cache to be cleared. It must be somewhere in the folders contained within the /app folder – or simply uploading that many files (circa 15,000) causes the cache to clear.

So, I corrected my local.xml settings on my development server (correct for the live server that is) and am currently uploading the whole lot again. Fingers crossed.

Update:

Amazingly this didn’t work! I decided to take the step of backing up my database, deleting the local.xml file and proceeding through the standard install wizard. This went smoothly and it seems that the install is clever enough not to overwrite you tables, or data when they already exist so it is a reasonably painless process. I would always recommend you back up your database, not least in case this changes in future versions of Magento.

I will update to let people know if this was actually a success or not.

  • http://www.jimcode.org James Rowe

    Ah it works! I still hope there is a better way of solving this – but at least there is a solution.

  • http://salin.org Steve

    You’re really not selling me on Magento:P

  • http://www.jimcode.org James Rowe

    Well there are loads of problems like this – and much of it is undocumented but the basic system gives you a huge amount of functionality easily. Just about worth the frustration in my book – but only just!