I downloaded the files and nailed down the most obvious environmental variables before even trying to run the client’s script in my local environment. No biggie – create a dupe of the database and the db user, make sure the script connects to my local instance of MySQL, etc. I knew the script should run since it worked well already in the client’s production environment.

Once the tweaking was done I gave it a try and immediately saw this error:

Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result

My first thought was that I’d missed something with the local variables because the actual line of code that PHP puked on looked fine. I tested the SQL query, ran through the code a few times and began to seriously worry about my competence.

But then I realized all of the PHP open tags were written in short form:

—

<?

// various PHP code

?>

—

By default, WAMP does not support the short open tag. All I had to do was enable that particular setting in WAMP’s PHP settings, and PRESTO: instant functionality.

I’ve read several forums where this error appeared for other developers, but none of the forums said anything that connected the PHP setting of short open tag support. Hopefully this will help somebody someday.

When browsing to the sites they both produced the same MySQL error #145. And it was the session table that was corrupted on both DBs.

The first thing I thought of was some hack-bot going around exploiting some little-known Joomla vulnerability. But I haven’t been able to find anything about that on the Joomla site. Or elsewhere.

I then wondered if it was perhaps my hosting company, Hostmonster.com. The company president has a blog that sometimes explains strange new behavior in my hosting account. Sure enough there was an entry about changes they’ve been making that may well have had an impact. Turns out they’re switching their storage to Solid State Drives (SSDs).

But then I found a couple old Joomla threads indicating that Joomla has long suffered from periodically corrupted session tables.

Even if it does turn out to be a Joomla issue, why would they both happen pretty much on the same day? I’ve never seen it before.

If anyone has any ideas, feel free to let me know.

I’m usually able to simply copy/paste the last site I made for her and customize it for the new year and school. However, the last reunion site I did included a photo gallery. And, apparently, the extension I used to provide the photo gallery functionality stashed a bunch of images into the DB.

Which means, of course, when I went to copy the last site’s DB, the SQL file was rather large – 57 MB – much larger than GoDaddy will allow for importing into a new DB via phpMyAdmin.

GoDaddy tech support turned me on to this new technique. If you arrived here through a search on this subject, I hope it helps. I couldn’t find anything about it when I needed it.

Note: This information is only relevant to people using GoDaddy hosting accounts who need to import a large SQL file. I also assume you know how to get around GoDaddy’s control panels.

1. Dump the old database into a SQL file. If it’s less than 2 or 3 MB, you can probably just use phpMyAdmin for the import and skip all of what follows.
2. On the NEW hosting account, create a fresh MySQL DB using the tools GoDaddy provides.
3. After the setup of the DB is complete (takes several minutes), do a backup of the new DB. Yes, even though it’s empty.
4. Again, this will take a few minutes. While you’re waiting FTP the SQL file from the old DB into the _db_backups directory in your HTML directory.
5. Go back to your NEW DB, and do a restore. It will ask you which file you want to use. Use the big fat SQL file you just FTP’d to the new hosting account.
6. The new DB will be populated with the old DB’s content.

If you found this page and used this workaround, let me know. Thanks.