Running update.php for upgrade on a small site:

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'hoslot5_ghhoa.profile_field' doesn't exist: SELECT DISTINCT(category) FROM {profile_field}; Array ( ) in profile_user_categories() (line 502 of /home/hoslot5/public_html/modules/profile/profile.module).

Just looking for a pointer if the problem has been addressed, thanks.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Starminder’s picture

Version: 7.0 » 7.4

Anyone?

lyricnz’s picture

Was profile module enabled on your D6 site before the upgrade? What version of Drupal 6 are you upgrading from?

I don't know why profile_user_categories() would be called during update.php

lyricnz’s picture

Perhaps a contributed module on your site is calling profile_user_categories(). Can you search your site for references to "profile_user_categories"? Paste results here.

Starminder’s picture

Believe profile was enabled, yes. Was upgrading from 6.22 to 7.0 - now at 7.7 still getting same error. I ran a search on core and on modules but nothing found.

Jean Gionet’s picture

getting the exact same message after upgrading from 6.22 to 7.7

lyricnz’s picture

Unable to reproduce. Can either of you provide a DB dump of a Drupal 6 site that is exhibiting this issue? Feel free to sanitize users table etc as required, and send me a msg with the location.

Starminder’s picture

I did notice just trying to visit the broken site results in:
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'hoslot5_ghhoa.blocked_ips' doesn't exist: SELECT 1 FROM {blocked_ips} WHERE ip = :ip; Array ( [:ip] => 96.231.239.220 ) in drupal_is_denied() (line 1635 of /home/hoslot5/public_html/includes/bootstrap.inc).
Seems related.

lyricnz’s picture

Looks like the upgrade failed in the middle, or wasn't run. That table should have been created by "system" module. If you run /update.php - does it say that updates are pending?

Starminder’s picture

Running update results in the original error.

Starminder’s picture

This is what I'm left with that's not running, just wish I knew what was blocking it:

The following updates returned messages
user module
Update #7006

Failed: PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'weight' in 'order clause': SELECT r.rid AS rid, r.name AS name FROM {role} r ORDER BY weight ASC, name ASC; Array ( ) in user_roles() (line 2797 of /home/hoslot5/public_html/modules/user/user.module).

system module
Update #7067

Failed: PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'weight' in 'order clause': SELECT r.rid AS rid, r.name AS name FROM {role} r INNER JOIN {role_permission} p ON r.rid = p.rid WHERE (p.permission = :db_condition_placeholder_0) ORDER BY weight ASC, name ASC; Array ( [:db_condition_placeholder_0] => access administration pages ) in user_roles() (line 2797 of /home/hoslot5/public_html/modules/user/user.module).

services module
Update #7301

Failed: DatabaseSchemaObjectDoesNotExistException: Cannot add field services_endpoint.debug: table doesn't exist. in DatabaseSchema_mysql->addField() (line 320 of /home/hoslot5/public_html/includes/database/mysql/schema.inc).

node module
Update #7008

Failed: PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'weight' in 'order clause': SELECT r.rid AS rid, r.name AS name FROM {role} r INNER JOIN {role_permission} p ON r.rid = p.rid WHERE (p.permission = :db_condition_placeholder_0) ORDER BY weight ASC, name ASC; Array ( [:db_condition_placeholder_0] => administer nodes ) in user_roles() (line 2797 of /home/hoslot5/public_html/modules/user/user.module).

arh1’s picture

For what it's worth (it wasn't quite explicit above), I was able to work around a very similar error to the one from the original post by simply disabling the Profile module, upgrading D6 to D7, then enabling Profile again.

Reg’s picture

I'm getting the same error however I have a native D7 install, that is there was never a D6 from which I upgraded. I have xdebug running so I can show you the stack trace:

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'dm_7_bh_stage.profile_field' doesn't exist in /www/drupal/includes/database/database.inc on line 2137

Call Stack:
    0.0027     806920   1. {main}() /www/drupal/update.php:0
    0.2551   42110808   2. update_fix_compatibility() /www/drupal/update.php:419
    0.2561   42129944   3. update_check_incompatibility() /www/drupal/includes/update.inc:28
    0.2635   41504064   4. system_rebuild_module_data() /www/drupal/includes/update.inc:52
    0.2635   41504400   5. _system_rebuild_module_data() /www/drupal/modules/system/system.module:2422
    1.2776   60959288   6. drupal_alter() /www/drupal/modules/system/system.module:2394
    1.2776   60959416   7. user_system_info_alter() /www/drupal/includes/module.inc:1004
    1.2776   60959496   8. db_table_exists() /www/drupal/modules/user/user.module:3930
    1.2776   60959496   9. DatabaseSchema_mysql->tableExists() /www/drupal/includes/database/database.inc:2730
    1.2776   60959688  10. DatabaseConnection_mysql->queryRange() /www/drupal/includes/database/mysql/schema.inc:502
    1.2776   60960232  11. DatabaseConnection->query() /www/drupal/includes/database/mysql/database.inc:68
    1.2777   60962472  12. DatabaseStatementBase->execute() /www/drupal/includes/database/database.inc:664
    1.2777   60962520  13. PDOStatement->execute() /www/drupal/includes/database/database.inc:2137

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'dm_7_bh_stage.profile_field' doesn't exist in /www/drupal/includes/database/database.inc on line 2137

Call Stack:
    0.0027     806920   1. {main}() /www/drupal/update.php:0
    0.2551   42110808   2. update_fix_compatibility() /www/drupal/update.php:419
    0.2561   42129944   3. update_check_incompatibility() /www/drupal/includes/update.inc:28
    0.2635   41504064   4. system_rebuild_module_data() /www/drupal/includes/update.inc:52
    0.2635   41504400   5. _system_rebuild_module_data() /www/drupal/modules/system/system.module:2422
    1.2776   60959288   6. drupal_alter() /www/drupal/modules/system/system.module:2394
    1.2776   60959416   7. user_system_info_alter() /www/drupal/includes/module.inc:1004
    1.2776   60959496   8. db_table_exists() /www/drupal/modules/user/user.module:3930
    1.2776   60959496   9. DatabaseSchema_mysql->tableExists() /www/drupal/includes/database/database.inc:2730
    1.2776   60959688  10. DatabaseConnection_mysql->queryRange() /www/drupal/includes/database/mysql/schema.inc:502
    1.2776   60960232  11. DatabaseConnection->query() /www/drupal/includes/database/mysql/database.inc:68
Reg’s picture

Version: 7.4 » 7.8

I should mention that I don't even see "profile" under "Core" in the modules section. Is that normal?

Also, unlike D6 (this is my first time with D7) I don't see a "core extra/optional" section but I'm guessing is this just way D7 is.

I'll try and get the system table to rebuild and see if it makes any difference.

This history is: installed D7.7, upgraded to D7.8, started enabling some contributed modules, now trying to run update.php and getting this error.

Reg’s picture

So I looked at the profile.info file and saw that profile is now hidden so it's only there for legacy reasons. I then unhid it thinking I could install it so that at least the table would exist and as soon as I did I got the same error but this time through only looking at the module page in Drupal.

My guess is from this behavior there are two errors. First, the update.php file is not always respecting the hide flag in the .info file but also the profile.module code may also have a bug that shows itself when the module has never been initialized - I'm not sure how/if that is possible but that's how it looks. That's my best guess at the moment but will try to dig a little deeper.

Reg’s picture

Okay, here is a temporary workaround to this problem:

Edit profile.info and change: hidden to: hidden = FALSE
You may need to clear the caches at this point (I use the admin module for this)
Go to the module page
If enabled, disable the profile module and Save, it won't be by default.
Enable the profile module and save. This will create all the tables for that module.
Disable the profile module and Save since this is the default. If it was enabled when you first looked at it then it might need to be enabled in your case, you will have to make that determination.
Set hidden = TRUE again in the profile.info

Just be sure to not "uninstall" the module at any time (like when you are doing some clean up) as this will remove the tables it created.

Clearly this is only a workaround because why this is happening in the first place needs to be figured out and fixed.

smk-ka’s picture

I'm getting the same output as in #12, on a pure D7 site that never had profile enabled. The error suddenly started to appear appeared after resetting the database using an SQL dump and executing a drush cache-clear all.

lyricnz’s picture

@smk-ka: careful, applying a SQL dump file will not necessarily drop all the tables that exist in the database (it only does a DROP+CREATE for the tables it knows about, meaning that any tables that aren't in your DB dump (eg: D6 tables) will be left intact (eg: D7 dump)).

anieves’s picture

All errors about 'PDOException bla bla bla table not exists bla bla bla' is caused by xdebug module, disable in PHP and all errors will be hidden.

At least in my case.

Best Regards.

smk-ka’s picture

Yes, more specifically, it is the xdebug.show_exception_trace setting that triggers a stack trace whenever an exception is raised - even if that exception is actually caught.

Reg’s picture

Yes and no regarding #18.

xdebug will not "generate" an error/exception. It will "expose" them and more specifically, it will give you far more detail than if you don't have it running. After all, it is a "debugging" tool, that's what it is supposed to do.

Of course, why the exception is happening in the first place should still be tracked down and a code change made to eliminate it.

anieves’s picture

Yes I known. XDebug isn't the cause, it's only to view Exception's trace. I used XDebug and ZendDebugger since many years, sorry for my bad expresion :P

Reg’s picture

Got it, no worries.

Neubian’s picture

#15 works for me. Thanks Reg. I tried all kinds of suggestions to no avail before this finally got it.

Anonymous’s picture

Version: 7.8 » 7.12
Category: support » bug

The issue is that profile_update_7001() isn't executed before some other portion of the upgrade is accessing the profile module. To work around the error I renamed profile_tables to profile_table and profile_values to profile_value manually with phpMyAdmin. I was upgrading from 6.24 to 7.12. I assume the issue to be accessing the user functions to determine if the user has permissions to run update.php.

EDIT: At the end of the update.php module I had to rename the two tables back to the original values and re-execute update.php to allow profile_update_7001 to complete without error.

mgifford’s picture

Robin Monks’s picture

I can vouch for this still happening on latest 7.x; is there a fix in sight for this highly aggravating bug?

/Robin

gregsomers’s picture

I am upgrading from 6.22 to 7.14 and gett his error.

In my case table name in D6 is "profile_fields" not "profile_field". If I change the name of the table the error goes away.

Anonymous’s picture

Priority: Normal » Major

In my case table name in D6 is "profile_fields" not "profile_field". If I change the name of the table the error goes away.

Yes this is the simple work around. I haven't had time to take a look at the code but something is out of order or hasn't been committed to the DB causing this issue. This is a major issue because you can't continue with the upgrade until you work around the problem. The first error aborts the process leaving the database in partial update state.

Anonymous’s picture

; The Profile module is deprecated, and included in Drupal 7 for legacy
; purposes only. By default, the module will be hidden from the UI unless you
; are upgrading a site that uses the Profile module to extend user profiles.
; See user_system_info_alter().
hidden = TRUE

So why was the table renamed, why not just leave it alone!!!? (this sarcastic remark needs no comment from others)

Something is calling one of the hook implementations within the user module that causes the profile_user_categories (which is itself a hook implementation of hook_user_categories) to be called before the profile module hook_update_N that renames the table has a chance to execute.

catch’s picture

Status: Active » Postponed (maintainer needs more info)
Issue tags: +D7 upgrade path

I can only reproduce anything like this with xdebug.show_exception_trace = 1. Please rule that out if you're getting this error. And if you still are getting the error, please paste a backtrace to this ticket.

andros’s picture

I have had this error during upgrade from D6 to D7:
An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: /update.php?op=selection&token=0B-2lvx1jcvkJe-RoiSx5zKbC9xoE2zA1vo1BwqEKvM&id=58&op=do StatusText: Service unavailable (with message) ResponseText: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Tabelle 'kksd.drupal_profile_field' doesn't exist: SELECT DISTINCT(category) FROM {profile_field}; Array ( ) in profile_user_categories() (line 502 of /srv/pub/drupal/modules/profile/profile.module).

After that i have just start from from the backup again but this renamed the table before start update.php to profile_field.
This time the upgrade progress finishes but after that there was this message:

Notice: Undefined index: update_success in update_results_page() (line 167 of /srv/pub/drupal/update.php).
Warning: reset() expects parameter 1 to be array, null given in update_results_page() (line 171 of /srv/pub/drupal/update.php).
Warning: array_pop() expects parameter 1 to be array, null given in update_results_page() (line 171 of /srv/pub/drupal/update.php).

I have tried to load /admin but it loads only a blank page. So trunked the cache tables (again), didn't helps, Then i just run update.php again and it shows 2 more upgrades one was to rename profile_fields to profile_field. So i renamed it again back to profile_fields and start update.php. It finished with an error. So far the sites seems to be okay since then.

jackbravo’s picture

disabling profile before upgrading is a workaround.

szantog’s picture

Category: bug » support
Status: Postponed (maintainer needs more info) » Active

This is obviously not a core issue right now.

The facts:

  1. In core there are correct update path for profile module.
  2. profile_user_categories() is an implemented hook, I don't explain any reason to call it from hook_update_N

But here is a detailed case: The module strongarm have a ctools dependent update hook. The ctools have a content type plugin based on profile module, so ctools can't be disabled during the update process by default. The ctools import own plugins during some registry rebuild, and it uses profile_user_categories() for checking.

If some core guru agree this, I think, this issue can be closed.

Anonymous’s picture

Category: support » bug

This isn't a support request, it is a bug, maybe not a core bug but it is still a bug.

@szantog: Are you saying that one of the ctools modules is the culprit for calling the profile_user_categories() in one of its hook_update_N? If so then change the Project to ctools.

szantog’s picture

@earnie
Not on hook_update_N
see: http://drupalcode.org/project/ctools.git/blob/10a2674c4cd0c3344c2ae9616c...

You are right, this is the ctools issue: #1835392: Using profile_user_categories() breaks major core upgrade
This is my case, what I was talking about, there should be other modules which use profile_user_categories() wrong way. But this can't be a core issue.

Anonymous’s picture

Priority: Major » Minor
Status: Active » Postponed (maintainer needs more info)

Correct. Setting to postponed until #1835392: Using profile_user_categories() breaks major core upgrade becomes resolved.

This does not affect D8 since the profile module has been removed.

hass’s picture

Version: 7.12 » 7.19
Priority: Minor » Major
Status: Postponed (maintainer needs more info) » Active

I have the same issue:

An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: http://localhost/update.php?op=selection&token=[id]&id=3&op=do StatusText: Service unavailable (with message) ResponseText: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'foo.profile_field' doesn't exist: SELECT DISTINCT(category) FROM {profile_field}; Array ( ) in profile_user_categories() (line 502 of modules\profile\profile.module).

This is correct as the D6 table in the database is named "profile_fields" and not "profile_field". Maybe this is caused by ctools... investigating.

[profile_fields.inc]

if (module_exists('profile') && !is_null(profile_user_categories())) {
hass’s picture

Project: Drupal core » Chaos Tool Suite (ctools)
Version: 7.19 » 7.x-1.2
Component: profile.module » Code

Removed ctools and panels from modules folder and update succeeded.

ctools is the source of this bug! It has a weight of 0 and profile module, too. Since we are ordering and running update hooks based on alphabetical order and weight, ctools comes before profile module update hooks. Therefore the profile_fields table has not yet renamed to profile_field, but the profile_user_categories() is called inside ctools and cause the update batch to crash.

I'm not sure how we are able to detect if we are running inside an update.php to extend the above condition and skip this if we run inside update.php. We may check for MAINTENANCE_MODE constant. Otherwise we need to change the weight of ctools, what looks not like a good solution to me.

Workaround: Remove ctools and dependent modules from the modules folder and run the update of core. Afterwards copy the modules back and run the remaining updates.

merlinofchaos’s picture

Status: Active » Closed (duplicate)

Marking dup as per #35, then.

hass’s picture

Version: 7.x-1.2 » 7.x-1.x-dev
Status: Closed (duplicate) » Needs review
FileSize
952 bytes

Patch attached has been tested with an upgrade and fixes the bug.

hass’s picture

Cross post, but this case has a patch now and I closed the #1835392: Using profile_user_categories() breaks major core upgrade case for this reason.

hass’s picture

Component: Code » Plugins system
dgtlmoon’s picture

Status: Needs review » Reviewed & tested by the community

great, worked for me

aaron’s picture

I confirm that this patch does indeed work as advertised.

podarok’s picture

Assigned: Unassigned » merlinofchaos

looks like good for me too
RTBC #40

hass’s picture

I ran myself into this issue again. This suxxx a lot. Why is this still sitting in queue and not committed?

hass’s picture

Priority: Major » Critical

Broken module makes this critical. Please create a new release.

fonant’s picture

Patch in #40 works for me.

japerry’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.