updating Rules fails due to missing dirty table

Just had exactly the same thing after updating Entity API to latest dev version and clearing cache. Clearing cache using Drush gives the same result as with admin menu shortcut.

No idea what the problem is. Are you using dev or regular Entity API module?

Trying to clear cache again from seperate tab gives this:

Catchable fatal error: Object of class stdClass could not be converted to string in /...path.../includes/theme.inc on line 2439

(my theme is a subtheme of omega in case that is relevant, also drupal 7.7)

Yes - that fixed it for me too. The error was killing even drush but going to sitename.com/update.php?op=info worked fine.

For me, I updated modules using Drush so never saw anything about an update. It seems that while updating the database for Rules module (or possibly Imagecrop - Rules seems more likely), drush crashed for reasons unknown, which then caused this.

I got this while upgrading rules-beta1 to -rc1. Not sure what that implies. Thanks to alanomaly for the fix, as updating or doing pm-* through drush wasn't working.

Error:

$ drush pm-update
Drush command terminated abnormally due to an unrecoverable error.   [error]
PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'base.dirty' in 'field list': SELECT base.id AS id, base.name AS name, base.label AS label, base.plugin AS plugin, base.active AS active, base.weight AS weight, base.status AS status, base.dirty AS dirty, base.module AS module, base.data AS data
FROM
{rules_config} base
WHERE  (base.plugin IN  (:db_condition_placeholder_0, :db_condition_placeholder_1, :db_condition_placeholder_2, :db_condition_placeholder_3, :db_condition_placeholder_4)) ; Array
(
    [:db_condition_placeholder_0] => or
    [:db_condition_placeholder_1] => and
    [:db_condition_placeholder_2] => action set
    [:db_condition_placeholder_3] => rule
    [:db_condition_placeholder_4] => rule set
)
 in EntityAPIController->query() (line 152 of /var/aegir/platforms/ff-2.4/sites/all/modules/entity/includes/entity.controller.inc).

yep, I also ran into this once when updating rules with drush. Running update.php works though, so I guess it's a problem with the drush updater invoking some hooks before running the update.

I'm also having this problem with the Rules upgrade. Any version higher than Beta 2 seems to cause this on my site, and running the upgrade script doesn't do anything for me.

Ok, I was able to get it working, but had to completely delete all the database tables for rules and re-install.

I got the same issue trying to update to 7.x-2.3 using drush [drush up rules]. I tried again from within the Drupal GUI and it worked fine. Maybe a Drush issue.

Security updates will be made to the following projects: Rules [rules-7.x-2.3]

Note: A backup of your project will be stored to backups directory if it is not managed by a supported version control system.
Note: If you have made any modifications to any file that belongs to one of these projects, you will have to migrate those modifications after updating.
Do you really want to continue with the update process? (y/n): y
Project rules was updated successfully. Installed version is now 7.x-2.3.
Backups were saved into the directory /Users/awagner/drush-backups/austingo_030613/20130329132916/modules/rules. [ok]
WD php: PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'base.dirty' in 'field list': SELECT[error]
base.id AS id, base.name AS name, base.label AS label, base.plugin AS plugin, base.active AS active, base.weight
AS weight, base.status AS status, base.dirty AS dirty, base.module AS module, base.access_exposed AS
access_exposed, base.data AS data
FROM 
{rules_config} base
WHERE  (base.status IN  (:db_condition_placeholder_0, :db_condition_placeholder_1, :db_condition_placeholder_2))
; Array
(
    [:db_condition_placeholder_0] => 3
    [:db_condition_placeholder_1] => 2
    [:db_condition_placeholder_2] => 6
)
 in EntityAPIController->query() (line 152 of
/Applications/MAMP/htdocs/austin-go.030613/austin-go/sites/all/modules/entity/includes/entity.controller.inc).
Drush command terminated abnormally due to an unrecoverable error.                                               [error]
PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'base.dirty' in 'field list': SELECT base.id AS id, base.name AS name, base.label AS label, base.plugin AS plugin, base.active AS active, base.weight AS weight, base.status AS status, base.dirty AS dirty, base.module AS module, base.access_exposed AS access_exposed, base.data AS data
FROM 
{rules_config} base
WHERE  (base.status IN  (:db_condition_placeholder_0, :db_condition_placeholder_1, :db_condition_placeholder_2)) ; Array
(
    [:db_condition_placeholder_0] => 3
    [:db_condition_placeholder_1] => 2
    [:db_condition_placeholder_2] => 6
)
 in EntityAPIController->query() (line 152 of /Applications/MAMP/htdocs/austin-go.030613/austin-go/sites/all/modules/entity/includes/entity.controller.inc).Backups were restored successfully.                                                                              [ok]

EDIT: when I tried to push the code to Prod, we can't update through the GUI as there's no FTP access and all is pushed through GIT. I found that if I disabled the Rules module, pushed the code, ran update.php then re-enabled the Rules module it seemed to work. Otherwise I got the White Screen of Death

[deleted]

The 'dirty' column in the {rules_config} table was committed in issue #1223028: care about broken Rules on 17 Aug 2011 and was included in Rules 7.x-2.0-rc1.

Apparently, updating with drush from versions prior to 7.x-2.0-rc1 to versions later than that caused a problem for some users. The last report of a problem with this update was more than five years ago.

Anyone installing Rules over the past 7 years will not see this problem. If you do see this problem, that means you're trying to update a site that hasn't been updated in more than seven years. Usage statistics shows there are only about 200 sites using versions of Rules that old, out of more than 285,000 sites total. So IMO it's not worth the time or effort to try to fix this for that small number of users who are very out of date with improvements to Rules and Drupal. There is a workaround above if you still need it.