Magento – Fix Error ‘Invalid Backend Model Specified’

The catalog_product_index_eav table has a foreign key contraint named

FK_CAT_PRD_IDX_EAV_ENTT_ID_CAT_PRD_ENTT_ENTT_ID

Looking at this table's definition

CREATE TABLE `catalog_product_index_eav` (
  `entity_id` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'Entity ID',
  `attribute_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Attribute ID',
  `store_id` smallint(5) unsigned NOT NULL DEFAULT '0' COMMENT 'Store ID',
  `value` int(10) unsigned NOT NULL DEFAULT '0' COMMENT 'Value',
  PRIMARY KEY (`entity_id`,`attribute_id`,`store_id`,`value`),
  KEY `IDX_CATALOG_PRODUCT_INDEX_EAV_ENTITY_ID` (`entity_id`),
  KEY `IDX_CATALOG_PRODUCT_INDEX_EAV_ATTRIBUTE_ID` (`attribute_id`),
  KEY `IDX_CATALOG_PRODUCT_INDEX_EAV_STORE_ID` (`store_id`),
  KEY `IDX_CATALOG_PRODUCT_INDEX_EAV_VALUE` (`value`),
  CONSTRAINT `FK_CATALOG_PRODUCT_INDEX_EAV_STORE_ID_CORE_STORE_STORE_ID` FOREIGN KEY (`store_id`) REFERENCES `core_store` (`store_id`) ON DELETE CASCADE ON UPDATE CASCADE,
  CONSTRAINT `FK_CAT_PRD_IDX_EAV_ATTR_ID_EAV_ATTR_ATTR_ID` FOREIGN KEY (`attribute_id`) REFERENCES `eav_attribute` (`attribute_id`) ON DELETE CASCADE ON UPDATE CASCADE,
  CONSTRAINT `FK_CAT_PRD_IDX_EAV_ENTT_ID_CAT_PRD_ENTT_ENTT_ID` FOREIGN KEY (`entity_id`) REFERENCES `catalog_product_entity` (`entity_id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Catalog Product EAV Index Table';

we can see the foreign key definition is

CONSTRAINT `FK_CAT_PRD_IDX_EAV_ENTT_ID_CAT_PRD_ENTT_ENTT_ID` 
FOREIGN KEY (`entity_id`) 
REFERENCES `catalog_product_entity` (`entity_id`) 
ON DELETE CASCADE ON UPDATE CASCADE

This means for every entity_id row in catalog_product_index_eav, there needs to be an identical, corresponding entity_id value in catalog_product_entity.

The root of your problem is for some reason (either a rouge extension, errors caused by randomly typing in SQL from the internet, or performing data updates with disabled indexes), Magento's indexing attempts to update data in catalog_product_index_eav that violates this rule. The next step is identifying what Magento's doing so you can fix the data.

If we look at your call stack, this looks like a good place to start debugging

#10 app/code/core/Mage/Catalog/Model/Resource/Product/Indexer/Eav/Abstract.php(54): 
Mage_Index_Model_Resource_Abstract->syncData()

Jumping to that source file, we see the following bit of code

public function syncData()
{
    $this->beginTransaction();
    try {
        /**
         * Can't use truncate because of transaction
         */
        $this->_getWriteAdapter()->delete($this->getMainTable());
        $this->insertFromTable($this->getIdxTable(), $this->getMainTable(), false);
        $this->commit();
    } catch (Exception $e) {
        $this->rollBack();
        throw $e;
    }
    return $this;
}

As part of its indexing process, Magento tries to sync data from an "index table" (getIdxTable), to a "source" (getMainTable) table.

public function insertFromTable($sourceTable, $destTable, $readToIndex = true)
{
    //...
}

For this particular index, the index table is catalog_product_index_eav_idx, and the source table is catalog_product_index_eav.

Note: Be careful with your terminology around here, things are confusingly named. The "Source" table is the table we're copying to. (I believe it's called the source table because it's the "source" a normal Magento system will query from when it needs information)

So, Magento is trying to sync a row from catalog_product_index_eav_idx to the table catalog_product_index_eav. However, this causes the previously mentioned foreign key error. This leads us to two possible conclusions

1. The catalog_product_index_eav_idx has entity_id rows that do not exist in catalog_product_entity.

2. The catalog_product_index_eav table has (through previous manipulation with index checks turned off) entity_id rows that do not exist in catalog_product_entity.

So, your mission here is to figure out which entity_id rows in catalog_product_index_eav and catalog_product_index_eav_idx don't exist in catalog_product_entity, and manually delete said rows (from catalog_product_index_eav and catalog_product_index_eav_idx).

If it were me, and my catalog_product_entity table wasn't too large, I'd start with the following queries (these are untested, as I don't have any Magento tables with the above invalid data states)

SELECT * 
FROM catalog_product_index_eav_idx 
WHERE NOT (entity_id IN (SELECT entity_id from catalog_product_entity));

SELECT * FROM catalog_product_index_eav 
WHERE NOT (entity_id IN (SELECT entity_id from catalog_product_entity));

Good luck!

Ok so I am not sure if this is the bug but if you compare the Magento 1.8 and Magento 1.7 versions of the function currency in Mage_Core_Model_Local you will notice a reference to a bug with Zend_Currency

Magento 1.7: Mage_Core_Model_Local->currency

/**
 * Create Zend_Currency object for current locale
 *
 * @param   string $currency
 * @return  Zend_Currency
 */
public function currency($currency)
{
    Varien_Profiler::start('locale/currency');
    if (!isset(self::$_currencyCache[$this->getLocaleCode()][$currency])) {
        try {
            $currencyObject = new Zend_Currency($currency, $this->getLocale());
        } catch (Exception $e) {
            $currencyObject = new Zend_Currency($this->getCurrency(), $this->getLocale());
            $options = array(
                    'name'      => $currency,
                    'currency'  => $currency,
                    'symbol'    => $currency
            );
            $currencyObject->setFormat($options);
        }

        self::$_currencyCache[$this->getLocaleCode()][$currency] = $currencyObject;
    }
    Varien_Profiler::stop('locale/currency');
    return self::$_currencyCache[$this->getLocaleCode()][$currency];
}

Magento 1.8: Mage_Core_Model_Local->currency

/**
 * Create Zend_Currency object for current locale
 *
 * @param   string $currency
 * @return  Zend_Currency
 */
public function currency($currency)
{
    Varien_Profiler::start('locale/currency');
    if (!isset(self::$_currencyCache[$this->getLocaleCode()][$currency])) {
        $options = array();
        try {
            $currencyObject = new Zend_Currency($currency, $this->getLocale());
        } catch (Exception $e) {
            /**
             * catch specific exceptions like "Currency 'USD' not found"
             * - back end falls with specific locals as Malaysia and etc.
             *
             * as we can see from Zend framework ticket
             * http://framework.zend.com/issues/browse/ZF-10038
             * zend team is not going to change it behaviour in the near time
             */
            $currencyObject = new Zend_Currency($currency);
            $options['name'] = $currency;
            $options['currency'] = $currency;
            $options['symbol'] = $currency;
        }

        $options = new Varien_Object($options);
        Mage::dispatchEvent('currency_display_options_forming', array(
            'currency_options' => $options,
            'base_code' => $currency
        ));

        $currencyObject->setFormat($options->toArray());
        self::$_currencyCache[$this->getLocaleCode()][$currency] = $currencyObject;
    }
    Varien_Profiler::stop('locale/currency');
    return self::$_currencyCache[$this->getLocaleCode()][$currency];
}

My suggestion would be to try updating the try catch to match that of Magento 1.8 (I know this is not the best solution and obviously I would not suggest editing the core files but adding a rewrite)