The "problem" occurred again - the one that, by virtue of its dogged recurrence, has drawn my typewriting fingers' attention not once but twice before. It goes like this: I try to so much as edit an old entry, save a new one, access my templates, export posts or rebuild my weblog and a famous MySQL error - "Statement has no result columns to bind" - pops up, denying me further usage of uBlog. Sometimes one or more of these symptoms is not present, for instance the error message not appearing, or the template list functional. But by one component failing, the process itself is otherwise hobbled.
This began in February, as soon as I started placing Movable Type's database into MySQL format as opposed to Berkeley Database (and no, I can hardly tell you the internal differences between the two; I know where to put operative folders and little more). It happened off and on, usually once a week or less. But it was irritating, nonetheless: how long could a spell last? Usually, a few hours or a morning. Over the past month, however, outages have lasted entire days.
I've got plenty of reasons not to blog at a given point in time but waiting for some obscure, obstinate wrench in the cogs is not on the list of excuses.
Movable Type's help forum was of only modest help; Benjamin Trott and others have done more than enough with providing every miniature Twain or Fitzgerald an easy, global interface that's just as easily customized as it is instantly recognizable in format - so it's not surprising that they offered only a few thoughts before shrugging their shoulders and advising me to pick up the trail.
So I did. I called my provider, Core Comm, around July 4th: big mistake. The tech was probably already penning in his holiday weekend and gave me a vague promise of either a solution or a report; I let him go without a due time. Another big mistake. I never heard back from him.
The heels of this lapse in customer service coincided with a mysterious absence of the scourge (which now makes a bit of sense, explained below) so I let the matter blow in the wind for the better part of three weeks.
Last Saturday, I was hit with my first all-day-no-blogging experience. I wasn't exactly about to post an epistle, but there was Movable Type, bugging out, and being conscious of the loss was extremely annoying. Something akin to stubbing a toe or waking up with a sore throat; once it's done and you're thoroughly convinced of your less-than-optimal physical state, you compulsively put weight on the gammy foot or swallow hard just to check if the condition may have healed over the past, oh, four minutes or so from any given point in time. So part of the day involved my succumbing to a strange vacuum that lodged itself in my computer room, sucking me inside every time I walked past, followed by my repeated, somewhat arduous clicking of certain execution-function keyboard buttons, followed by consternation and cartoon steam piling out from both my ears. Followed by vain Google searches for that Holy Grail of case history accounts, followed by more consternation, followed by my storming out of the room, in spite of the vacuum. Before the vacuum pulled me back inside again.
Sunday morning, all was well. But for how long? Well, this morning, while getting ready, I was trying to accomplish something extremely innocuous - Movable Type conked out again.
That was enough. I called Core Comm, spoke to a girl named Natalie, and - thankfully - did not need to extract a promise of investigation and diagnosis in a timely fashion. I hung up, satisfied, and waited while I worked.
Within two hours she called back, with a report not unlike what Benjamin Trott surmised: the problem was not caused by Movable Type or the MySQL database themselves. "Server load," she explained, caused by either throughput or disk space limitations, was overwhelming at certain usage periods and subsequently incapacitated communication actions - in this case, my software's communication with the database. That would explain, I thought, the inconsistent nature of the malfunction itself; not to mention the inexplicable, random restoration of operation. Moreover, the week following the Fourth of July appeared to be a popular week for vacations, and I can only assume the liquidity on asphalt roads was matched by smooth conduction through broadband wires.
There was a pleasant, if not exactly cut-and-dried, end to the story. Core Comm was "in the process of making more room for the servers" to handle these excessive usage hours, said Natalie, "and it's an ongoing thing." I tried to pin her down on benchmarks for the project, but she held firm with the "ongoing" aspect of it. Not my favorite scale of measurement, but both "on" and "going" are tonic to the schedule-minded.
When I left for lunch, the outage remained. But now - surprise! - you're reading this. A round of applause, please. My Movable Type installation is okay, my database is intact: Core Comm intends to fix the server problem. Fair enough.