“Invalid parameter number: no parameters were bound”

 When people used our search feature on our site, a few specific search terms would result in un-caught exceptions. Of course, this ONLY happened on the client’s server. Nothing like saying a project is solid, only to find out there’s something ‘special’ about the production environment.

The first thing we did, was to list out what was unique about the client’s server. The client was using a Media Temple box running CentOS 5.2. For the un-initiated, CentOS is the free version of Red Hat Enterprise Server. We run Macs in the office, and our staging server is a Mac too. Other than the OS, the normal ‘LAMP’ stuff pretty much matched verbatim. 

So, we started digging into the differences between the compiled versions of PHP between the development and production environments, and one thing popped out at us:

PCRE

The version that’s supported on Red Hat / CentOS is 6.6. That’s horrible. 6.6 came out nearly 3 years ago, and the version the client was running had no support for unicode at all. A little research, and we found out that Zend Search Lucene (what we built the search functionality on top of) requires unicode for the way it stores search indexes.

With that, we figured we were done. The client had a limitation on their server, they needed to address it, and the problem would fix itself when they did. Not quite so fast …

I was testing some of the searching on my iMac, when the same issue happened on my own computer. Disaster! Could it be that something in our own code was the culprit? What half-reproducible error was causing this? 

After hours of searching for an answer on the googlez, I came across some help on the Zend Issue Tracker. It turns out, that PDO was failing when it was trying to prepare a statement, when that statement contained a question mark. When I switched my SQL adapter to Mysqli, the problem was solved. Both the production and the development environments were bug free after the change.

It turns out, that our search indexes would return fields that either contained question marks, because they actually existed in the document (as was the case locally), or because the document had encoding errors when the search index was built (as was the case on the production servers). The ORM we used would grab the documents, and grab relevant data from the database by querying with the fields stored in the index.

The SQL that was being prepared, would then look something like this:

‘SELECT id FROM folks WHERE first_name LIKE ‘Jo?hnny’

The question marks would be interpreted by PDO as variable markers, which rightfully didn’t exist.

So, the real solution wound up being a little bit of a mix between the client’s problem, and our own. Granted, we needed to catch question marks being stored in db before they got there. That improves the longevity of our own code. However, the search functionality will still return results that may have question marks in them, thus causing the same issue. That issue is resolved by using Mysqli, but that feels more like a hack, than a solution.

Anyways, I spent a long time trying to search the answer to this and found nothing except the one mention in the issue tracker. For those of you using Zend Lucence Search on Red Hat / CentOS servers. Make sure you use Mysql if you’re using the Zend ORM to populate models based on results returned from the index. 

Oh yeah, and make sure you filter your input too, Mr. Bobby Tables…..

So, I got some tools from my buddy Derek, and got to work on it tonight. Taking apart a macbook is a delicate thing to do, and should be taken seriously. I laughed when my wife suggested I just screws into a bag so I didn’t lose them. Ideally, one should have a clean white surface to place screws that mimics the placement of them in the actual computer.

Anyways, after about an hour of disassembly and inspection, I figured out the issue. One of the brackets that sit above the CD / DVD drive was lodged underneath the CD / DVD player. I fixed the issue and re-assembled the computer in about 10 minutes. Not bad if I may say so myself.

Then I went to install Leopard .

The first time I attempted the install, I got everything started and left the machine alone. When I went to check on it about a half hour later, I saw a large notification that the install had failed. I tried to restart the machine to re-attempt the install a few times. Each time however, the installer couldn’t find the HD to install to.

Finally, I got a notification that the HD was formatted in a way that was incompatible for Leopard. If I proceeded with the install, I was going to have to wipe the HD clean. That was a bit daunting to hear, since my wife is the primary user of the computer. If I lose something she cares about, well, I don’t have to tell you the horrors I’d face then.

So, I got out my handy-dandy external HD. It’s really just a shell with an old 120GB IDE thrown in there, but it does the job well. I got everything I could figure she might want off of the computer, and re-started the install process.

When the computer asked where to install Leopard, I recieved the same prompt as before, but this time I went ahead with the install, knowing that I was formatting the hard drive.

After the format was complete, the installer proceeded. I left the machine alone, figuring that I had a while before I needed to do anything with it. About another half hour later I checked on it, only to see another “Install Failed” screen. Now I was in a serious bind: would my wife be without a computer at all?

Well, I’ve always been one to keep trying until something gives up and works for me . So, I re-started the install again. This time however, I was happy to see that it worked! I went through the typical post-install steps, and was delighted to see my wife’s macbook successfully running Leopard.

The one issue that did come up afterwards however, was all my iLife apps were gone. I suppose I can’t complain too much about it. I didn’t pay for the original iLife apps, so I’m not out any money. But still, It’d be really nice to not have to buy soemthing I already had on here.

I recommended a Windows SBS 2003 box. The client obliged.

All was fine until the issue of VPN came up. I’ve done VPN’s before, but usually it’s through hardware, not through the OS. The client eventually was paid in full, and the issue still wasn’t completely resolved. I felt terrible about it, so I made it my priority to fix. The client was really cool, and I didn’t want them to feel cheated or upset in any way.

I won’t go through the whole tutorial on how to setup an SBS box, but I will say that usually, it’s very intuitive. Well, when I set up the box, I configured it to work on one subnet. However, the modem supplied to the client wouldn’t allow GRE packets through, so they needed to get a new modem.

When that modem arrived, it didn’t work with their existing Linksys wireless router. So I used the modem as the router, and plugged the wireless box into it, and ran it as a separate subnet. Keep in mind, this was after I had already configured the SBS box for the previous subnet.

I thought I had configured the server to work with the new network settings, but I missed a couple of items.

Clear ARP cache.

Since RRAS was started, you couldn’t clear the ARP cache (the table with the addresses of machines according to the old subnet). I had to stop the RRAS service to clear the ARP cache. Keep that in mind if you have to move an SBS box from one network to another.

Change ALL network settings. When I changed the TCP/IP information for the network adapter (only one), I only changed the information on the front dialog box. Which means I forgot to change the WINS information! Since the client was using VPN so he could navigate to files on the network, that was pretty important.

Also, I needed to add the dns suffix to the DNS settings area as well.

The moral of the story, take the time to get it done right the first time.

After a brief search on Google, I came up with a German forum with a potential solution: APC (Alternative PHP Cache). It turns out that Caching for PHP 5.2 is different than for PHP 5.0. So, I turned of APC (by editing the php.ini file).

For all of you coders out there, just an FYI.