Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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.
Comment | File | Size | Author |
---|---|---|---|
#40 | ctools_1157526+A+Error+on+D6+to+D7+upgrade+PDOException+SQLSTAT.patch | 952 bytes | hass |
Comments
Comment #1
Starminder CreditAttribution: Starminder commentedAnyone?
Comment #2
lyricnz CreditAttribution: lyricnz commentedWas 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
Comment #3
lyricnz CreditAttribution: lyricnz commentedPerhaps 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.
Comment #4
Starminder CreditAttribution: Starminder commentedBelieve 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.
Comment #5
Jean Gionet CreditAttribution: Jean Gionet commentedgetting the exact same message after upgrading from 6.22 to 7.7
Comment #6
lyricnz CreditAttribution: lyricnz commentedUnable 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.
Comment #7
Starminder CreditAttribution: Starminder commentedI 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.
Comment #8
lyricnz CreditAttribution: lyricnz commentedLooks 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?
Comment #9
Starminder CreditAttribution: Starminder commentedRunning update results in the original error.
Comment #10
Starminder CreditAttribution: Starminder commentedThis 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).
Comment #11
arh1 CreditAttribution: arh1 commentedFor 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.
Comment #12
Reg CreditAttribution: Reg commentedI'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:
Comment #13
Reg CreditAttribution: Reg commentedI 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.
Comment #14
Reg CreditAttribution: Reg commentedSo 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.
Comment #15
Reg CreditAttribution: Reg commentedOkay, 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.
Comment #16
smk-ka CreditAttribution: smk-ka commentedI'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
.Comment #17
lyricnz CreditAttribution: lyricnz commented@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)).
Comment #18
anieves CreditAttribution: anieves commentedAll 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.
Comment #19
smk-ka CreditAttribution: smk-ka commentedYes, 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.Comment #20
Reg CreditAttribution: Reg commentedYes 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.
Comment #21
anieves CreditAttribution: anieves commentedYes 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
Comment #22
Reg CreditAttribution: Reg commentedGot it, no worries.
Comment #23
Neubian CreditAttribution: Neubian commented#15 works for me. Thanks Reg. I tried all kinds of suggestions to no avail before this finally got it.
Comment #24
Anonymous (not verified) CreditAttribution: Anonymous commentedThe 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.
Comment #25
mgiffordPossibly related issue #517742: Upgrade failing if blocked_ips doesn't exist
Comment #26
Robin Monks CreditAttribution: Robin Monks commentedI can vouch for this still happening on latest 7.x; is there a fix in sight for this highly aggravating bug?
/Robin
Comment #27
gregsomers CreditAttribution: gregsomers commentedI 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.
Comment #28
Anonymous (not verified) CreditAttribution: Anonymous commentedYes 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.
Comment #29
Anonymous (not verified) CreditAttribution: Anonymous commentedSo 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.
Comment #30
catchI 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.Comment #31
andros CreditAttribution: andros commentedI 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.
Comment #32
jackbravo CreditAttribution: jackbravo commenteddisabling profile before upgrading is a workaround.
Comment #33
szantog CreditAttribution: szantog commentedThis is obviously not a core issue right now.
The facts:
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.
Comment #34
Anonymous (not verified) CreditAttribution: Anonymous commentedThis 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.
Comment #35
szantog CreditAttribution: szantog commented@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.
Comment #36
Anonymous (not verified) CreditAttribution: Anonymous commentedCorrect. 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.
Comment #37
hass CreditAttribution: hass commentedI have the same issue:
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]
Comment #38
hass CreditAttribution: hass commentedRemoved
ctools
andpanels
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 toprofile_field
, but theprofile_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.
Comment #39
merlinofchaos CreditAttribution: merlinofchaos commentedMarking dup as per #35, then.
Comment #40
hass CreditAttribution: hass commentedPatch attached has been tested with an upgrade and fixes the bug.
Comment #41
hass CreditAttribution: hass commentedCross 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.
Comment #42
hass CreditAttribution: hass commentedComment #43
dgtlmoon CreditAttribution: dgtlmoon commentedgreat, worked for me
Comment #44
aaron CreditAttribution: aaron commentedI confirm that this patch does indeed work as advertised.
Comment #45
podaroklooks like good for me too
RTBC #40
Comment #46
hass CreditAttribution: hass commentedI ran myself into this issue again. This suxxx a lot. Why is this still sitting in queue and not committed?
Comment #47
hass CreditAttribution: hass commentedBroken module makes this critical. Please create a new release.
Comment #48
fonant CreditAttribution: fonant commentedPatch in #40 works for me.
Comment #49
japerryFixed and Committed:
http://drupalcode.org/project/ctools.git/commit/fec33a9fb13e50b73d3ae718...