db_columns blank for some number fields after upgrade
| Project: | Content Construction Kit (CCK) |
| Version: | 6.x-2.4 |
| Component: | number.module |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
I'm performing a D5 -> D6 upgrade. At first I thought I had the same problem as #363668: CCK fields are not showing up in Views but this doesn't seem the case.
I am scripting this upgrade and (amongst other things) this:
- Disables all non-core modules.
- Put new D6 code base in.
- Re-enable all non-core modules.
I manually run upgrade.php
- Do further tweaks to complete upgrade.
This works well. I have numerous CCK fields that upgrade just fine. However, it seems only one of them is not being properly converted - a number with select widget with 3 defined values. I have another such number field in the system with 4 defined values that is being properly converted which is odd. I mean, it's odd one would work and the other not when they are basically identical.
Anyhow, I noticed this while upgrading the views that use these fields as the 3 value one was missing. At first thought this must be an integration issue but on further investigation do not think that is correct.
When I look in the content_node_field table I notice the db_columns field is blank for the CCK number field am having problems with. The other number field has something in there. Surely that is a big clue.
I don't recall any errors during upgrade but will re-run and see if I can glean any more information to help here.
#1
I just re-ran the upgrade and was wrong when I said, "The other number field has something in there. Surely that is a big clue."
Both the number fields have blank db_columns and neither appear in views content list.
Checking further I found that it's the
content_associate_fieldsfunction that fills this column. This should be called fromcontent_check_updatebut for some reason that hasn't happened.Forcing an update of the last number module install (
number_update_6000) fixes this, but it would still be nice not to have to do this.I guess the issue is more related to one of the above functions not properly executing during upgrade.
#2
I would say... a) make sure it works in the source site, then b) upgrade manually and see if there is any error reported. Just in case, review the upgrade instructions and follow the steps carefully.
Many sites have upgraded successfully, so this seems something odd in your environment. Switching to support request...
#3
I had exactly the same problem. As suggested by raintonr above , manually selecting number_update_6000 to run when running update.php solves the problem.
Thanks a ton for the tip raintonr. May be this is actually a bug after all.
Abhaya