I'm running into the following error with my Linux install of MT 4.1 RC2

Statement has no result columns to bind (perhaps you need to successfully call execute first) at /.../extlib/Data/ObjectDriver/Driver/DBI.pm line 120.

This error occurs when I'm managing entries and I choose to go to the second page. I've expanded to 100 entries to per page without any problems, it's only when I try to navigate beyond the initial page that this error occurs. I AM able to go entry-by-enty though, however that is a bit tedious.


What I've Tried
1. I've rebuilt all the tables

2. I've disabled all plugins

3. I've rebuilt all the blogs

4. I've just downloaded the latest build, it's unclear if it's different than what I have, and I'm uploading it now.


Anyone have any ideas on how to fix this?

Thanks in advance.

I am now getting the same exact problem (incl. same "DBI.pm line 120") on my MT 4.01 blog. I installed as a clean install on UNIX with MySQL as DB (mt-check.cgi passed all required tests, etc.). Had no problems whatsoever building 2 blogs and doing all sorts of changes to static templates, new entries, style sheets, etc. I imported about 40 entries via a .txt file to one blog, but that didn't seem to cause any problems.

Then, one day, I started noticing (not sure if I tried this earlier) that the "next" button on entry lists (from admin console) would throw the "Statement has no result columns to bind..." error. No matter what screen I was on, if there was a list of things (entries, assets, etc.) and a "next" link/icon to go to the second page of things, clicking this link would result in this error. As I did not have that many things yet, I ignored it. Everything else worked fine.

Then, just the other day, after unpublishing all my entries and creating a single new one, and then shortly afterwards republishing about six of my original entries, I discovered I was no longer able to use the "publish" feature to publish pages, archives, etc. Seems if I just publish the indexes I'm okay, but anything else (including "all") throws me this same grievous error again, and again, and again. Now I can't make any changes to my widgets, templates, or anything else!

I've read all the posts and advice I could searching Google for anything about this problem, and even repaired all the tables on my database as one person recommended as a solution, but no good. I am considering reinstalling the entire site and using the old database, but some people seem to suggest that this did not always solve the problem.

So, is there ANYONE who knows how to actually resolve the deadly "STATEMENT HAS NO RESULT COLUMNS TO BIND.../DBI.PM line 120" error? Anyone? Please?

I can't solve it but I can add my experience of the problem.

I get the error message when loading the dashboard with no blog id in the command line eg:


and if I try loading a non-existent blog id: (I had previously deleted the first blog)


But this works fine (for a blog id that does exist:)


(I get the same result whether or not I use FastCGI)

I've been through the usual database tables cleaning and repairing stuff too. I'm using MT 4.01.

Could this be something to do with the configuration of MYSQL? Its like MT is struggling identifying default values or something?

So, you get this just trying to log into the application?



Why would this ever happen?
Besides hacking the URL, which brings up all sorts of "enough rope" arguments.

I've never encountered this, but a couple things to check out:
First thing I'd try(all of you) is ripping out any and all plugins to simplify the situation. If that does clear things up, then add them back in one by one to figure out which is causing the problem.
You also might try reading over this blog post and trying the debug config directive to see if you get the same results.

Well, Su's right (again!!)

In my case the MTMultiblog plugin seemed to be causing the difficulty. Disabling it cured the problem. I've yet to get to the bottom of it completely and I'm puzzled because that plugin is bundled. But the database I'm using has seen service all the way through the beta programme so almost anything could be happening in there. There's an entry in the mtplugindata table for it and I need to test with a new install whether I should be expecting that. If not, there's the answer for me anyway.

{Speculation}
If you've migrated a database from 3 to 4 (or like me you've gone through the beta) maybe there's some old plugin data lying around when its now not expected. So not a table needing to be repaired from MySQL's point of view, but now corrupt from MT's point of view.
{/Speculation}