The feature export included taxonomy terms, content type and a custom menu. Selection of these items also generated a list of custom fields , modules, & etc. Enabling the features module in the new site generated a this error message:

PDOException: SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'field_data_body' already exists: CREATE TABLE {field_data_body} ( `entity_type` VARCHAR(128) NOT NULL DEFAULT '' COMMENT 'The entity type this data is attached to', `bundle` VARCHAR(128) NOT NULL DEFAULT '' COMMENT 'The field instance bundle to which this row belongs, used when deleting a field instance', `deleted` TINYINT NOT NULL DEFAULT 0 COMMENT 'A boolean indicating whether this data item has been deleted', `entity_id` INT unsigned NOT NULL COMMENT 'The entity id this data is attached to', `revision_id` INT unsigned NULL DEFAULT NULL COMMENT 'The entity revision id this data is attached to, or NULL if the entity type is not versioned', `language` VARCHAR(32) NOT NULL DEFAULT '' COMMENT 'The language for this data item.', `delta` INT unsigned NOT NULL COMMENT 'The sequence number for this data item, used for multi-value fields', `body_value` LONGTEXT NULL DEFAULT NULL, `body_summary` LONGTEXT NULL DEFAULT NULL, `body_format` VARCHAR(255) NULL DEFAULT NULL, PRIMARY KEY (`entity_type`, `entity_id`, `deleted`, `delta`, `language`), INDEX `entity_type` (`entity_type`), INDEX `bundle` (`bundle`), INDEX `deleted` (`deleted`), INDEX `entity_id` (`entity_id`), INDEX `revision_id` (`revision_id`), INDEX `language` (`language`), INDEX `body_format` (`body_format`) ) ENGINE = InnoDB DEFAULT CHARACTER SET utf8 COMMENT 'Data storage for field 2 (body)'; Array ( ) in db_create_table() (line 2684 of C:\Documents and Settings\Administrator\My Documents\_web\CR\includes\database\database.inc).

refreshing the page generated this:

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'crhub.field_data_body' doesn't exist: SELECT COUNT(*) AS expression FROM (SELECT 1 AS expression FROM {field_data_body} field_data_body0 WHERE (field_data_body0.deleted = :db_condition_placeholder_0) LIMIT 1 OFFSET 0) subquery; Array ( [:db_condition_placeholder_0] => 0 ) in field_sql_storage_field_storage_query() (line 577 of C:\Documents and Settings\Administrator\My Documents\_web\CR\modules\field\modules\field_sql_storage\field_sql_storage.module).

The site is now inaccessible.

CommentFileSizeAuthor
#4 profile_sfj-7.x-1.0-beta1.tar_.gz2.34 KBsteinmb
#2 export_nodes.zip69.13 KBAshlar
#2 tax_terms.zip10.3 KBAshlar

Comments

hefox’s picture

hefox commented
Status: Active » Postponed (maintainer needs more info)

Thank you for providing the errors, but could you expand on what the situation was:

  • Was there a active content type with the body field?
  • Install profile?
  • Can you provide the feature that caused the bug?
Ashlar’s picture

Ashlar commented
Status: Postponed (maintainer needs more info) » Active
StatusFileSize
new tax_terms.zip10.3 KB
new export_nodes.zip69.13 KB

The site I am importing into is new. There are no additional content types or content other than what comes out of the box. I have attached two separate features that have crashed the site.

I am not sure what you mean by 'install profile'

mpotter’s picture

mpotter commented
Priority: Critical » Normal
Status: Active » Closed (cannot reproduce)

I was able to add both of those features (not at the same time, but separately) to a fresh Drupal site without the crash above (although see below)

1) Installed Drupal 7.10
2) Installed latest Features (1.x-dev version)
3) Downloaded your features and copied them to /sites/all/modules/features
4) Cleared cache and visited the /admin/structure/features page to make sure the features were listed and to see what their dependencies are.
5) I installed the dependency modules needed for each feature (link, node_export, relation) and enabled the needed modules. Note that the two features themselves conflict so you can't have them enabled at the same time.
6) Back on the Features page, I enabled the tax_terms feature. Cleared cache. No crashes
7) On the Features page, I disabled tax_terms and enabled export_nodes. Now I got errors because this feature exports some of the same stuff as the previous feature. Disabling a feature does not remove the content. Features doesn't want you to lose any data, so this is by design. If I enable export_nodes on a fresh site without first using tax_terms (so skipping step 6) then it works.

The bottom line is you need to clear out anything remaining in your site before turning on these features. They are meant to go onto a fresh/blank Drupal site.

I also highly suggest using Drush from the command line so you can manage your features even when the UI gives some errors.

These features use several different contrib modules, so all I can suggest is that you set up a fresh Drupal test site with your features and then slowly add other modules until you find the conflict. Make sure you are running the latest version of Drupal, latest version of Features, etc.

steinmb’s picture

steinmb commented
Status: Closed (cannot reproduce) » Active
StatusFileSize
new profile_sfj-7.x-1.0-beta1.tar_.gz2.34 KB

Reopening. Triggered this. Site a clean install with minimum core profile.

Env

PHP 5.3.3-7+squeeze8 with Suhosin-Patch (cli) (built: Feb 10 2012 14:12:26)
Drupal 7.15

Setup/problem

Minimum core profile.
One content type enabled by a another feature module.

drush en -y profile_sfj --verbose
Initialized Drupal 7.15 root directory at /var/www/250.sfj.no/drupal                                                                                                                            [notice]
Initialized Drupal site default at sites/default                                                                                                                                                [notice]
The following extensions will be enabled: profile_sfj
Do you really want to continue? (y/n): y
WD system: profile_sfj module enabled.                                                                                                                                                            [info]
WD features: Rebuilding profile_sfj / field.                                                                                                                                                    [notice]
WD php: DatabaseSchemaObjectExistsException: Table field_data_body already exists. in DatabaseSchema->createTable() (line 657 of /drupal/includes/database/schema.inc).   [error]
Cannot modify header information - headers already sent by (output started at /usr/local/drush/includes/output.inc:37) bootstrap.inc:1239                                                    [warning]
DatabaseSchemaObjectExistsException: Table <em class="placeholder">field_data_body</em> already exists. in DatabaseSchema->createTable() (line 657 av /drupal/includes/database/schema.inc).
Drush command terminated abnormally due to an unrecoverable error.

Debugging

Det installer is correct, the table exist. and I get:

SELECT entity_type, bundle FROM field_data_body;
+-------------+--------+
| entity_type | bundle |
+-------------+--------+
| node        | blog   |
+-------------+--------+
1 row in set (0.00 sec)

though the blog module is not installed.

steinmb’s picture

steinmb commented
Version: 7.x-1.0-beta6 » 7.x-1.0
steinmb’s picture

steinmb commented
Category: bug » support

Not so sure that this is bug. Did some more testing based of what I found debugging #4. Tried to install blog module since field_data_body contain data origin from it. Also core blog module blows up.

Uninstalled blog module and dropped these two tables.

DROP TABLE field_data_body;
DROP TABLE field_revision_body;

Blog now install/uninstall correctly. The same goes for my super small features module. The real question is, how do we end up in this state? The table claimed that node/2 had stored content but that node was not on the system. Hm...

mikemadison’s picture

mikemadison commented
Related issues: +#1551132: When trying to create a table that already exists but is empty, recreate the table rather than throwing a DatabaseSchemaObjectExistsException

A better solution seems to be the patch proposed in #72 of https://www.drupal.org/node/1551132#comment-10799724, that fixed the problem in D7 for me

mpotter’s picture

mpotter commented
Status: Active » Closed (fixed)