Posted by sixscrews on June 13, 2012 at 1:21am
I have a site that runs in Drupal 6.26.
I setup a parallel site (copy of my WORKING 6.26 installation) then followed all the directions in UPDATE.TXT to update it to 7.14 and get the following error:
: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'rc_drupal_test.blocked_ips' doesn't exist: SELECT 1 FROM {blocked_ips} WHERE ip = :ip; Array
(
[:ip] => 184.60.30.21
)
in drupal_is_denied()
Any ideas?
ss/wb
Comments
More on update failure
When I run update.php on the 7.14 version of the site, I get the following error message:
PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'ssid' in 'where clause': SELECT 1 AS expression FROM {sessions} sessions WHERE ( (sid = :db_condition_placeholder_0) AND (ssid = :db_condition_placeholder_1) ) FOR UPDATE; Array ( [:db_condition_placeholder_0] => Insje1SLqWF7P60uEZzWBNa9ohnRdSf9T5CfBr_-UEA [:db_condition_placeholder_1] => ) in _drupal_session_write() (line 209 of /home/whazzat.com??/drupal7/includes/session.inc).
Note: whazztat.com?? is my website URL - changed to protect those foolish enough to rely on a community-supported CMS to manage a client's website...
The updater/installer says there are pending updates - a huge laundry list of every module known to Drupal - when I click on 'run updates' I get:
An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: http://whazzat?.com/drupal7/update.php?op=selection&token=ty0I0bzjTEpwmn... StatusText: OK ResponseText: {"status":true, "percentage":"5", "message":"Completed 6 of 132.\u003Cbr \u002F\u003EUpdating taxonomy module"}Uncaught exception thrown in session handler.PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'ssid' in 'where clause': SELECT 1 AS expression FROM {sessions} sessions WHERE ( (sid = :db_condition_placeholder_0) AND (ssid = :db_condition_placeholder_1) ) FOR UPDATE; Array ( [:db_condition_placeholder_0] => Insje1SLqWF7P60uEZzWBNa9ohnRdSf9T5CfBr_-UEA [:db_condition_placeholder_1] => ) in _drupal_session_write() (line 209 of /home/whazzat?.com/drupal7/includes/session.inc).
So, it seems I have a SQL problem - the existing SQL db that works with 6.x doesn't seems to defriend 7.x (or is defriended by 7.x).
Q - do I need 7.x? Should I waste any more of my client's time messing with this?
Thanks,
ss/wb
Dependable pre-owned engineer.
Many new parts.
Little rust. Some non-repairable frame damage but still steers straight.
Always starts on cold mornings.
=-=
whether or not you "need" D7 isn't something anyone can answer but you or your client. D6 will be sunset when D8 is released so eventually all sites will need to be upgraded.
The ease of upgrade is dependent on the complexity of the site in question and which contrib modules were in use.
you are using the Major version upgrade instructions and not the minor update instructions in UPGRADE.txt ?
D6 to D7 update
Hello VM:
Thanks for getting back to me.
I recently updated the site to 6.24 (the latest D6 version) w/o problems. This was the first part of the D6 to D7 destructions.
Then I created a clone site from that and tried the D7 update, following the major update instructions - I switched the theme to Garland and disabled all modules outside the core (required at least two iterations to resolve all dependent modules).
Then I copied all D7 files into my target directory ('targetsitename') and copied over the sites directory from the D6 instance.
Ran targetsitename/update.php and got the results in the previous posts.
This looks like an SQL problem but I would guess it's an issue with some residual D6 item.
Thanks, again, for your help. Perhaps I can pay you back someday.
wb
Dependable pre-owned engineer.
Many new parts.
Little rust. Some non-repairable frame damage but still steers straight.
Always starts on cold mornings.
Can someone please help me
This is the 2nd time I am trying to update from 7.12 to 7.14 - The first time I lost my entire site now I just re-uploaded all files and folder via my ftp except for the sites directory which was left alone. Once everything had uploaded to the FTP when I go to my site URL I see the following:
Fatal error: Call to undefined function views_ui_cache_load() in /home/josephsergio/mjmroyalties.com/includes/menu.inc on line 592
Can someone please help me!
=-=
@ sixscrews
Which contrib modules are in use? Does the Database use a prefix?
=-=
@ JosephSergio
Hijacking the thread of someone else makes the thread difficult to keep up with. Please create your own thread to start your own discussion and get aid. Thanks.
=-=
-del-
=-=
-del-
Back to the issue
I tried this again - resetting the clone site to the 6.24 release then following the instructions in UPDATE.TXT
Same result - cryptic mySQL error.
My client is ready to throw in the towel on Drupal - this is the latest in a series of problems going back three years.
Getting my thread hijacked is an incredible waste of time - I don't give a s___ about someone else's problems unless they can solve mine at the same time, but the hijacker sounded more 'me too' than "I have a similar problem and I solved it this way."
Anybody have anything constructive to add?
If not, I'm closing this thread and probably telling my client to trash Drupal in favor of a more stable CMS.
ss
Dependable pre-owned engineer.
Many new parts.
Little rust. Some non-repairable frame damage but still steers straight.
Always starts on cold mornings.
=-=
My advice is that the client should remain at 6.26 as it's still a viable release and locate a developer experienced in major upgrades of core from D6 to D7.
Thanks
Hello VM:
Good point - except why should I have to pull in another egghead when I'm an egghead myself?
It seems to me that the Drupal update process should be sufficiently robust to handle problems like I'm seeing w/o spawning another round of consultants - yes, I know that's what keeps many of us in beer and skittles and I live in the same ecosystem. That doesn't mean that I like it or that I like to see clients spending money fixing problems that should have been caught in the beta release. We rely too much on our clients being the testers of last resort - that's a path to extinction, as far as I can tell.
ww
Dependable pre-owned engineer.
Many new parts.
Little rust. Some non-repairable frame damage but still steers straight.
Always starts on cold mornings.
=-=
for the most part upgrades from major to major version have been very easy. D6 -> D7, however is more complex and grows in complexity depending on the complexity of the site (ie: which contrib modules are in use which may also required their D7 counterparts in the mix during upgrade. for example: CCK
Core upgrade paths aren't tested against the tens of thousands of combinations of contrib modules which may be in use. That's an impossible task and I believe you've enough experience to know this. Straight D6 -> to D7 upgrades tend to work perfectly well.
You've done little to explain how the site is constructed for most to offer any solid advice. Perhaps rather then a straight upgrade of the existing site, it should be reconstructed in D7 and then the content moved over. Though again, the complexity of the current site is what needs to be understood. If it's a site with 100 - 200 contrib modules you never well may have to thin that out and remove modules that aren't available for D7, or have been replaced in total.
In the opening post you discuss a MYSQL error that indicates the upgrade process can't locate a specific table in the installation. Have you confirmed the table is in the DB? I also notice that the error indicates that the DB tables are prefixed is this truly the case?