"cache_panels doesn't exist" error on update

that error disappeared for me once i disabled the CONTEXT module. it wasn't enough to update CTools to the latest dev. I had to completely disable context and all it's associated modules not only for drush to abort in the middle of updating the database; but for drush to work at all afterwards.

I confirm that this appears when installing the latest dev of panels. I replaced it with the stable version and the error message went away.
In my case the cache_panels table never existed in the database, as far as I can see from backups so its not caused by a sudden deletion of that table.

Set to Major since using the 'stable' version of Aug 12 2012 is not an option...seems to be incompatible with a number of recent changes in modules.
By the way, the exact error message that I get when updating panels to the latest dev is

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'health_d7.cache_panels' doesn't exist: TRUNCATE {cache_panels} ; Array ( ) in cache_clear_all() (line 165 of /home/health/public_html/includes/cache.inc).
The website encountered an unexpected error. Please try again later.

Did you run the database updates?

yes i did.

If you ran the database updates then it should have ran update 7303 which creates the 'cache_panels' table. Can you please check the 'schema_version' value in the {system} table for the main 'panels' table and let us know what it says?

If you have Drush installed you can fix the problem with the following command:

drush ev "\$schema = drupal_get_schema_unprocessed('system', 'cache');db_create_table(\$table_name, \$schema);"

Alternatively, change the 'schema_version' to '7302' and run the database updates again.

Are any of you using Panels Everywhere? Do you have any additional / custom caching modules that interact with Panels, eg Expire?

Can you please try downloading the dev release again?

I too am having the issue with the new cache table not being created:

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'databasenamehere.cache_panels' doesn't exist: TRUNCATE {cache_panels} ; Array ( ) in cache_clear_all() (line 165 of /.../includes/cache.inc).

Using:
Panels 7.x-3.3+63-dev 2014-Jan-31
Drupal 7.26

Prior to executing the update, these are the proposed changes:

2 PENDING UPDATES
panels module
• 7302 - Adding universally unique identifiers to panels.
• 7303 - Add a custom cache table for Panels.

No "cache_panels" table has been created in the database.

I was updating two different sites at the same time and the one with far less modules installed did not have the error but the larger site did.

The site that did not incur the error in question did indeed create a new "cache_panels" table:
SELECT *
FROM `cache_panels`
LIMIT 0 , 30

The D7.26 site that did have the error has this system table schema:
sites/all/modules/panels/panels.module
panels
module
1
0
7303

The D7.24 site that did not have the error has this system table schema:
sites/all/modules/panels/panels.module
panels
module
1
0
7301

The error was repeatable on the site having the error.

Did you see any errors during the update on the larger site? I wonder if update 7302 is timing out?

Only the one reported in #12:

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'databasenamehere.cache_panels' doesn't exist: TRUNCATE {cache_panels} ; Array ( ) in cache_clear_all() (line 165 of /.../includes/cache.inc).

From my limited knowledge, it appears that the error is on 7303 unless the process performs both at the same time or in reverse order. Most of my timeouts settings on my server are WAAAAY jacked-up so I can't see that being an issue unless it involves MySQL. Also, the process didn't take that long, have had other updates take longer.

Out of interest, has anyone applied any patches that would have changed the update # for Panels?

No, none here.

Just tried downloading it again, and running update.php, which did not complete due to the error:

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'databasename.cache_panels' doesn't exist: TRUNCATE {cache_panels} ; Array ( ) in cache_clear_all() (line 165 of /.../includes/cache.inc

FYI, I am not using drush.

Grrr...reverting...again.

Just to clarify, the version I used both times was 7.x-3.x-dev 2014-Jan-31

Same issue here at an update from 7.x-3.3 to 7.x-3.4. ctools is updated separately to 7.x-1.4.

Here is my output from drush:

Code updates will be made to the following projects: Panels [panels-7.x-3.4]

Note: A backup of your project will be stored to backups directory if it is not managed by a supported version control system.
Note: If you have made any modifications to any file that belongs to one of these projects, you will have to migrate those modifications after updating.
Do you really want to continue with the update process? (y/n): y
Project panels was updated successfully. Installed version is now 7.x-3.4.
Backups were saved into the directory                                                        [ok]
.../20140212170059/modules/panels.
WD php: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table              [error]
'drupal7_uschtrin.cache_panels' doesn't exist: TRUNCATE {cache_panels} ; Array
(
)
 in cache_clear_all() (line 165 of
.../includes/cache.inc).
Drush command terminated abnormally due to an unrecoverable error.                           [error]
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'xxx.cache_panels' doesn't exist: TRUNCATE {cache_panels} ; Array
(
)
 in cache_clear_all() (Zeile 165 von .../includes/cache.inc).Backups were restored successfully.                                                          [ok]

I've solved this issue with following 2 steps:

1st:

drush dl panels
Install location .../sites/all/modules/panels already exists. Do you want to overwrite it? (y/n): y
Project panels (7.x-3.4) downloaded to                                                       [success]
.../sites/all/modules/panels.
Project panels contains 5 modules: panels_node, panels_mini, panels_ipe, i18n_panels, panels.

and 2nd:

drush updb
The following updates are pending:

panels module :
  7302 -   Adding universally unique identifiers to panels.
  7303 -   Add a custom cache table for Panels.

Do you wish to run all pending updates? (y/n): y
Performed update: panels_update_7302                                                         [ok]
Performed update: panels_update_7303                                                         [ok]
Finished performing updates.

Now it works, but it's less than ideal. May is this an issue for 7.x-3.4 too?

Ciao
Ralf

@rwam: What command did you run the first time? You shouldn't have needed to download Panels again, simply running "drush updb" or "drush updatedb" should have been enough.

Same thing here as @rwam.
Today, needed 2 updates, ctools and panels.
Did a drush up, got the above error. Tried the drush fix to create panels cache, failed.

did a drush dl ctools, then drush updb, then drush dl panels and drush updb , and all is good now.

Updating from panels 7.x-3.3 via $drush up panels gives the same error

Confirming #21 worked for me,

I did it slightly out of order - drush dl panels, drush dl ctools, drush up

Seems like drush updb is executing cache clear before the update hook is being called. I have a fix idea, but will require a new release. sigh.

@DaminenMcKenna: I used drush up first without success. Next I use drush up ctools to update Chaos Tools separately. After that I tried drush up panels and drush updb. Only with the procedure described above I can update the project.

As I don't use drush, I created the database in phpmyadmin with the following sql line:
CREATE TABLE `cache_panels` ( `cid` varchar(255) NOT NULL DEFAULT '' COMMENT 'Primary Key: Unique cache ID.', `data` longblob COMMENT 'A collection of data to cache.', `expire` int(11) NOT NULL DEFAULT '0' COMMENT 'A Unix timestamp indicating when the cache entry should expire, or 0 for never.', `created` int(11) NOT NULL DEFAULT '0' COMMENT 'A Unix timestamp indicating when the cache entry was created.', `serialized` smallint(6) NOT NULL DEFAULT '0' COMMENT 'A flag to indicate whether content is serialized (1) or not (0).', PRIMARY KEY (`cid`), KEY `expire` (`expire`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Generic cache table for caching things not separated out...';

You would change the database name according to your database schema (suffix, prefix,...).
I got this line from a database dump and copy from other an cache table as it seems generic. Schema module says nothing wrong.

We, too, are having this issue. We did the security updates to CTOOLS, Webform, etc. that all came in today, and on some sites the update worked fine, and on others it’s failing. The complexity of the site (other modules installed) appears to be the determining factor.

I Updated the Issue to reflect that it affects the new stable 7.x-3.4 as well as the previous -dev release.

While I may have stepped out of line here (and if so, I apologize), I also took the opportunity to edit @jerry’s main Issue text to redact all references to internal path names and database names and prefixes, as that information would be valuable to black hats and script kiddies. I can’t do that for comments, of course, so all of you who’ve posted raw drush dumps here, you may want to edit them. You should never post dumps including any such info on this nor any other tech forums. Be assured that black hats have bots running scripts scraping these and other tech support and developer forums for just such info.

My preferred technique is to replace all such path portions and prefixes with a horizontal ellipsis character (“…”), which in a monospaced font such as is used in <code> and PHP blocks looks considerably different from three periods so it’s obvious that the path shown has the extraneous but potentially dangerous info redacted.

To type a horizontal ellipsis, you can either use [Alt] + ([0 Ins] [1 End] [3 Pg Up] [3 Pg Up]) on the numeric keypad only on a Windows system, or [Shift]+[Option]+[:;] on a Mac OS X system. You may also be able to use the HTML Named Entity “&hellip;” and/or the HTML Numeric Entity “&#133;” depending on the forum.

I also made the reference to the “unrelated” CTools issue into a proper Issue link, as well as inserted it as a Related Issue in the Issue Relationships.

This seems to be caused by Commit#: 599d24e. https://drupal.org/node/2184143

This might help some of you get this fixed.
From your modules directory:

git clone --branch 7.x-3.x http://git.drupal.org/project/panels.git; cd panels;
git checkout 1fc3afa
drush updb -y
cd ..
drush dl panels -y
drush updb -y

Gang,

The problem is, in part, because of the sequence of steps Drush takes when using the "update" aka "up" command - it downloads the new modules, then seems to spawn a new task to run the updates. As a result of this, using the "drush up panels" command repeatedly will not solve the problem, it's just repeating the same steps that are shown to fail.

An alternative to this is running "drush pm-updatecode" aka "drush upc", that just downloads the bare code changes (without touching the database updates), and then separately run "drush updb", I suspect this should work.

@japerry: Maybe you could talk to Moshe about it? I'm in IRC if you want to discuss anything (#drupal-seo, #drupal-nh).

Non drush version shown at #25 worked beautifully for me.

As long as you have access to you phpmyadmin,running that command creates the table and allows the update script to do its job without error.

Thanks rondev!!

I just drushed this by doing "drush dl panels", then "drush updb".

I tried "drush upc", from #28, but it behaved the same as "drush up" for me.

I tried updating to 3.4 today with drush and had this problem. The solution in #21 did not work for me, the update failed each time with the following drush output:

The following updates are pending:

panels module : 
  7302 -   Adding universally unique identifiers to panels. 
  7303 -   Add a custom cache table for Panels. 

Do you wish to run all pending updates? (y/n): y
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'actived7.cache_panels' doesn't exist                          [error]
Performed update: panels_update_7302          [ok]
Finished performing updates.           [ok]

And panels updates 7302 and 7303 were still pending, though 7302 appeared to have run?

I notice that 7303 Adds the custom cache table, so is it that these updates are in the wrong sequence?

I had to use the solution in #25 to manually create the cache table. Then the drush updb ran without error:

The following updates are pending:

panels module : 
  7302 -   Adding universally unique identifiers to panels. 
  7303 -   Add a custom cache table for Panels. 

Do you wish to run all pending updates? (y/n): y
Performed update: panels_update_7302          [ok]
Performed update: panels_update_7303           [ok]
Finished performing updates.          [ok]

Had a same issue with drush pm-update. Tried to update from Panels 7.x-3.3 to 7.x-3.4. Ctools 7.x-1.4.

This went just fine:

drush dl panels
drush updatedb

any simple solution for one without Drush ?

You might try the following:

Edit panels_update_7302() in panels.install and insert the following as the first line of the function:

  panels_update_7303();

This will make it trigger panels_update_7303 before it tries to do he changes in panels_update_7302, just in case that causes any problems.

Thanks DamienMcKenna

#34 worked.

What the post # 25 worked great for me.

As long as you have access to phpMyAdmin, run this command creates the table and allows the upgrade script do its work without error.

CREATE TABLE `cache_panels` ( `cid` varchar(255) NOT NULL DEFAULT '' COMMENT 'Primary Key: Unique cache ID.', `data` longblob COMMENT 'A collection of data to cache.', `expire` int(11) NOT NULL DEFAULT '0' COMMENT 'A Unix timestamp indicating when the cache entry should expire, or 0 for never.', `created` int(11) NOT NULL DEFAULT '0' COMMENT 'A Unix timestamp indicating when the cache entry was created.', `serialized` smallint(6) NOT NULL DEFAULT '0' COMMENT 'A flag to indicate whether content is serialized (1) or not (0).', PRIMARY KEY (`cid`), KEY `expire` (`expire`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Generic cache table for caching things not separated out...';

Rondev thank you very much!

I have inserted "panels_update_7303();" in function "panels_update_7302()" in panels.install file

Returned:

The following updates returned messages
panels module
Update #7302
•UUID column already present in the panels_display & panels_pane tables. Generated UUIDs for database-based panel displays and panes.
.

Seems ok ?:)
Thank You DamienMcKenna !

Non-drush user.
I tried #25 and successfully created the table but the update still refuses to run and if I check the system table, I'm running update 7301.

Please also keep an eye on #2195243: Loosing database connection during upgrade.

Looking at #2195243 I don't have any outstanding updates except for panels. Was CTools only a code update or was it also a database update?
When trying to run update.php I get a notice of Panels 7302 and 7303 as pending but they don't run.
The only error in my logs was the "SQLSTATE[42S02]: Base table or view not found: 1146 Table 'actived7.cache_panels' doesn't exist" related to the missing cache_panel table that went away after I created it

Update: Used Devel to uninstall and reinstall module. Now system table is correct (7303) and no more outstanding updates showing on update.php

#21 method via drush worked for me. Thank you

#19 worked for me

Thanks to many of the comments above, this worked for me:

drush dl ctools
drush updb
drush cc
drush dl panels
drush updb

Clear all caches on the 'cc'.

#32/#43 worked fine for me on two different sites (both staging sites, not tried on the production sites yet), after having updated all other modules (most noticeably ctools) using the regular drush up. So:
drush up ctools
drush updb (nothing needs to be done if drush up went fine)
drush dl panels
drush updb (now the two db updates are done)
drush up (just checking)

Update: it worked on 3 out of 4 live sites. The last one failed, but using the CREATE statement to set up the cache table did the trick. All fine now. Thx everybody for posting solutions!

HI, #36 work for me.
I am not have access to drush because my site is in a share server. I used phpmyadmin, and the solution works very well. Thanks for your help.
lem

#32 worked for me, which is essentially downloading the latest version of the module and installing it, then running update.php. Presumably you could do this manually instead of drush.

#36 seems to have done the job. On a shared server and the phpmyadmin did the trick. Thank You!

#25 worked for me. It can be run from drush like this:

drush sql-query 'CREATE TABLE `cache_panels` ( `cid` varchar(255) NOT NULL DEFAULT "" COMMENT "Primary Key: Unique cache ID.", `data` longblob COMMENT "A collection of data to cache.", `expire` int(11) NOT NULL DEFAULT "0" COMMENT "A Unix timestamp indicating when the cache entry should expire, or 0 for never.", `created` int(11) NOT NULL DEFAULT "0" COMMENT "A Unix timestamp indicating when the cache entry was created.", `serialized` smallint(6) NOT NULL DEFAULT "0" COMMENT "A flag to indicate whether content is serialized (1) or not (0).", PRIMARY KEY (`cid`), KEY `expire` (`expire`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT="Generic cache table for caching things not separated out...";'

#36 worked for me thx - must learn to use drush!

I experienced the same problem.
My solution was run these commands:

drush cc
drush dl ctools
drush updb
drush up

When I run the "updb" command, it updated also to schema version 7302 and 7303 from panels. I suppose was due to previous attempts to update panels module.
Hope it helps someone :)

I can confirm this bug. I tried to update via "drush up". Same behaviour like in #32 and this workaround works ;)

#34 is the fix. You must force the update to run in the correct order so that the tables are created.

#25 and then setting schema_version to 7300 for panels in system table all through phpMyAdmin. Ran update.php. Building the panels cache table was skipped, since it was manually created in #25, but everything else ran and I haven't had any other problems.

#34 works for me!

thanks!

Adding this to the beginning of the first line of the panels.install file like stated in #34 seems to have worked here:

  panels_update_7303();

Same problem here. #34 (followed by drush updb) works for me.

1. dl panels-7.x-3.x-dev (doesn't fix)
2. running drush updb (no updates required)
3. add panels_update_7303(); to install file (panels already installed, so not run)
4. SQL query in #36 (and #25 and #48) - WORKS!

I added "IF NOT EXISTS" and bookmarked the query since I will probably need it again on other databases

CREATE TABLE IF NOT EXISTS `cache_panels` ( `cid` varchar(255) NOT NULL DEFAULT '' COMMENT 'Primary Key: Unique cache ID.', `data` longblob COMMENT 'A collection of data to cache.', `expire` int(11) NOT NULL DEFAULT '0' COMMENT 'A Unix timestamp indicating when the cache entry should expire, or 0 for never.', `created` int(11) NOT NULL DEFAULT '0' COMMENT 'A Unix timestamp indicating when the cache entry was created.', `serialized` smallint(6) NOT NULL DEFAULT '0' COMMENT 'A flag to indicate whether content is serialized (1) or not (0).', PRIMARY KEY (`cid`), KEY `expire` (`expire`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Generic cache table for caching things not separated out...';

#48 worked for me.

I ran into this problem today with a live site. But following the instructions in comment #21 worked for me after trying many other things. I did:

- drush dl ctools

- Save over current location? Y

- drush dl panels

- Save over current location? Y

Then I was able to run a full "drush up" command and it worked :)

Thanks for this information, it was a real life saver!

#25 worked for me as well

#25 worked for me too.Thanks!

#34 worked for me. Thank you!

This same problem prevented drush pm-update from working for my sites.
I used (a fixed version of) #8 above:

drush ev "db_create_table('cache_panels', drupal_get_schema_unprocessed('system','cache'));"

Thanks to all of you and Damien McKenna in particular.

I was experiencing similar issue, until I realized that panels requires ctools, at the same time I had ctools that needs to be updated too, so I updated ctools first then updated panels. Problem solved.

COMMENT REMOVED because i made a mistake in modifying the panels.install. It now works ;-) Sorry.

For #34, it works:

<?php
  panels_update_7303();
?>

When I finished, it said:

The following updates returned messages
panels module
Update #7302

    UUID column already present in the panels_display & panels_pane tables. Generated UUIDs for database-based panel displays and panes.

What's means?

updating first ctools didn't solve the problem, but #63 did.. thank you..

Looks like adding

 // Issue #2188277: Sometimes the order of panels and ctools causes this update
  // to fail. Re-run 7303, which will skip gracefully if it already ran.
  panels_update_7303();

Works well. (edit: lets have the right update number here ;-) )

Nevermind. The issue is around how panels does revisions per schema. The cache table went into the original schema, causing this regression. I've made some changes below.

Try this and see if it fixes the issue:

Re-rolled patch based on code from #2187433: UUID update necessitates an explicit dependency on the updated Ctools that performs a check first to make sure you have ctools 1.4 installed before it tries to install panels.

I'm pretty sure the easiest fix is the one suggested by DamienMcKenna at #34

Edit panels_update_7302() in panels.install and insert the following as the first line of the function:

<?php
  panels_update_7303();
?>
This will make it trigger panels_update_7303 before it tries to do he changes in panels_update_7302, just in case that causes any problems.

For the less experienced. This means opening panels.install in the root of the panels module folder. Going down to line 405 and adding:
panels_update_7303();

So this (before):

/**
 * Adding universally unique identifiers to panels.
 */
function panels_update_7302() {
  // Load the schema.
  $schema = panels_schema_5();
  $msg = array();

Will become this (after):

/**
 * Adding universally unique identifiers to panels.
 */
function panels_update_7302() {
  // Load the schema.
  panels_update_7303();
  $schema = panels_schema_5();
  $msg = array();

It will give you a this message:
Update #7302
UUID column already present in the panels_display & panels_pane tables. Generated UUIDs for database-based panel displays and panes.

But that is just because the update is trying to run twice so it is ignored once. No worries and it all works fine :)

Cheers.

@japerry: might it be worth bumping panels_update_7303 to panels_update_7304 to help people who might have ran the updates but resulted in a borked site?

Hmm I don't think we should need to do that. Looking at the errors reported above, it seems to occur on 7302, probably when clearing the cache, and calling a table that doesn't exist because its in the schema but not yet added in 7303.

This should mean that 7303 was never executed, so the system table won't show 7303, it should show 7302 or 7301. I guess a question for those having this issue: "When you go back to try to update again, does it show 7302 and 7303 as pending updates?"

Non drush user

Ran the update and had the issue described so rolled back my database using backup and migrate and followed #34 and #71, everything appears to have worked out fine with the following output, although this is slightly different to the output others have reported:

The following updates returned messages

panels module

Update #7302
•Added panels_pane.uuid column. Added panels_display.uuid column. Generated UUIDs for database-based panel displays and panes.

@japerry: "When you go back to try to update again, does it show 7302 and 7303 as pending updates?"

Yes, after the failed update / cache clear a drush updatedb still showed both these updates as pending.

Fix in #71 did the trick for me.

@tripper54, did you try to re-run the updates with the changes in the patch I suggested, or did you just copy #71?

One other problem was found, its possible clear cache is throwing the error. There is a hook for flush caches which is probably causing the error to occur before the update is applied. I threw a check around this hook to check to make sure the table exists before updating.

This and the patch are pushed now.
http://drupalcode.org/project/panels.git/commit/8059bda

#25 and #36 worked for me.

I used the text of the query exactly as written - I tried replacing the table name with the one reported in the error message, but that only failed differently.

I also received the Panels #7302 message.

Interestingly - I run two separate hosts in this configuration. The first one updated just fine, except that I saw the Panels #7302 message. The second one crashed and burned with the PDOException.

#25 worked for me as well.

Thank you.

#19 worked for me too

Non drush version shown at #25 worked beautifully for me as well.

#19, downloading panels and updating the db, worked for me

#43 worked for me
thanks to all

#21 worked for me.

thanks

drush up in 7.25 failed for me as well when the cache tables were not available. Following the reco in #21 (drush dl ctools, drush dl panels, drush up) resolved the issue and worked for me as well.

Thanks bioborg!

#21 worked for me. Thanks!

I have same problem here. I want to update the module but I can't.
when I want to patch the module [by copying the patch file into the module directory (7.x-3.3 version) and using cygwin64 command "C:\cygwin64\bin\patch.exe -p1 < C:\xampp\htdocs\rgpars\sites\all\modules\panels\2188277-panelscache-schema-2.patch" or even using p0 instead of p1]
I face with the error that says :

can't find file to patch at input line 5
perhaps you used the wrong -p or --strip option?
the text leading up to this was:
-------------------------------------------------
diff --git a/panels.install b/panels.install
index b913012ab645d1be40e2176f516844910822e6b6..196afd10675f46443751fd2b838df45aea04a0ec 100644
--- a/panels.install
+++ b/panels.install
-------------------------------------------------
file to patch:

I would appreciate if you give me the reason behind this error?

#43 worked for me.

#71 worked for me, but columns uuid in tables were filled by NULL.

I tried open one of my panels and save it - after that rows have got uuid (for that panel).

And then I took part of code from #7302 (from " // Add the uuid column to the display table." till end) and run it in devel's "run php".
All rows have got uuids.

update

I have tried to apply patch from #70 (after base reverting to panels 3.3). Patch applied, but I recieve the same error when run update.php.

update 2

I've tried to comment 7303 (with patch #70) but nevertheless get:
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'xxx.cache_panels' doesn't exist: TRUNCATE {cache_panels} ; Array ( ) in cache_clear_all() (line 165 of xxxxx\includes\cache.inc).

update 3

After several attempts I go to solution in #25 - create table by phpMyAdmin.
But even so - columns uuid filled by NULL! though after update.php I have recieved:
Update #7302
Added panels_pane.uuid column. Added panels_display.uuid column. Generated UUIDs for database-based panel displays and panes.

So I copied code from 7302 and run it with devel-php.
Now all is ok - all uuids recieved values...

Got this error today when updating panels to 7.x-3.4 in drush and the easy fix was to step back in database "system" table and set "schema_version" for "panels" to 7301 so the updates are executed on "drush updb"

Run this query:
UPDATE system SET schema_version = '7301' WHERE name = 'panels';
or by using drush sql query:
drush sqlq "UPDATE system SET schema_version = '7301' WHERE name = 'panels';"

Nothing here solved my problem. I ended up rolling back to 3.3 and running this query to create the cache.panels, after which the update went through fine:

CREATE TABLE `cache_panels` (
`cid` varchar(255) NOT NULL DEFAULT '' COMMENT 'Primary Key: Unique cache ID.',
`data` longblob COMMENT 'A collection of data to cache.',
`expire` int(11) NOT NULL DEFAULT '0' COMMENT 'A Unix timestamp indicating when the cache entry should expire, or 0 for never.',
`created` int(11) NOT NULL DEFAULT '0' COMMENT 'A Unix timestamp indicating when the cache entry was created.',
`serialized` smallint(6) NOT NULL DEFAULT '0' COMMENT 'A flag to indicate whether content is serialized (1) or not (0).',
PRIMARY KEY (`cid`),
KEY `expire` (`expire`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Generic cache table for caching things not separated out...';

Creating the table per millionleaves' sql got me through my update with no trouble.

#34 worked and was super easy. Thanks!

#25 worked for me. Just used "drush sql-cli" and used the "create table" command there. Thanks!

drush dl panels ctools
(overwrite: yes)
then:
drush updatedb
(prompt to create new panels cache table: yes)
then you can:
drush up

A note to those looking -- this fix is *not* in the Recommended release yet, so if you're upgrading with Drush it will fail (assuming you're not telling Drush to pull -dev versions).

I'm looking at #21 - how is" drush dl ctools, then drush updb" different from "drush up ctools" ?

I think drush bootstraps at a different time depending on how you run the command.

been pulling my hair out ever since i updated from panels 7.x-3.3 to 7.x-3.4

Installed Git GUI / Cygwin and tried to install the working patch >> waste of time for novice users like myself.

#25 - rondev - I knew i needed the schema, was looking in all the wrong places. thank you so much for sharing.
copied/pasted/hit go! >> worked >> i still have some hair left. ;)

#36 fixed this for me, we were getting the issue of the cache_panels table not being able to clear, then we deleted it (stupidly....) once we updated Panels then it obviously needed the table back!!!

Thanks!

#36 also worked for me

I had been having trouble upgrading Panels from D6 to D7.34, using Panels 7.x 3.4, which presumably fixed this error. I tried #34, for example, to no avail.

For anyone running into this problem and landing on this thread at a point in time after my comment here, what worked for me was this:

1. Enable only the Panels module first, by itself
2. Leave Mini Panels, Panel Nodes and Panels In-Place Editor disabled
3. Leave jQuery Update disabled
4. Run update.php
5. Enable jQuery update
6. Run update.php
7. If you use them, enable Mini Panels, Panel Nodes and Panels In-Place Editor
8. Run update.php

[Edit- if you need to revert to a backup, don't forget to uninstall Panels and jQuery update before trying to re-enable the modules above]

[Update- Lies! I must have uninstalled Panels in 6 before enabling in 7 because when I did all my panels were missing (I had two, so not really a big deal). Started from scratch again and got the same error. Ultimate solution was to disable and uninstall Panels in 6 before upgrading to 7. I am going to try to rebuild those portions of my site using views only, and, if I need to, re-install and re-enable Panels fresh in 7 (and hope my tables have been cleared out from the uninstall in 6) and rebuild any panels if need be (and I think there will be a need, as one of my goals here in upgrading to 7 was for my site to be responsive).

I don't yet trust myself with drush or running queries in my database, and some of the patches in this thread did not really work either. So, for those of us non-coders out here, this was a tough issue. Thankfully, I did not have many panels and could work around this...for now.

After I rebuild my site in 7 (mostly clean-up I've always wanted to do -- only a few things that did not work right, like some bits in my field migration (whay can't it deal with the hidden formatter?), but that's another thread -- it'll be on to try my hand at sub-theming a responsive base theme. Wish me luck...]

upgrading from drupal 6 to 7 and getting this error.

From the comments above my fixed was to set schema_version in table system to 7302,
run drush updb which happily creates the table
then set schema_version to 7301 and run drush_update again to pickup on update 7302

Everyone this problem has been confirmed. No need to keep confirming it. Additionally most of these fixes are quick fixes not a case for a permanent fix.

I am still running into this issue. The problem is being caused by panels_save_display in update 7302 which calls panels_clear_cached_content. Trying to think of a better fix.

What I have done is reversed the updates. I don't see any issue with doing this.

Last patch was bad

Does this fix the problem? Rather than rearranging the updates, which is a bad thing to do, call panels_update_7303() from within panels_update_7302().

Think I got it right this time.

@DamienMcKenna I really am not a fan of calling one update from another. I think the better solution is to change the update numbers. Do you see any issue with doing that?

@pwaterz: You should combine the two changes into a single diff, or manually recreate it from scratch, the patch you're uploading is confusing the testbot.

As for the direction to take, lets see what japerry thinks.

Sorry, trying to create this patch from an non standard context, let's try again lol.

Ignore that...I need to do this when I am not so busy.

FYI for this scenario my perspective is that you're more likely to cause problems for sites that were using an older dev release by reordering the updates than you are to fix them in-place.

This worked for me via drush:
> drush php-eval "module_load_install('panels'); panels_update_7303();"
> drush php-eval "module_load_install('panels'); panels_update_7302();"
> drush cc all

#119 worked for me!
@fsanfili Genius never would have thought to do it this way.

Hi there!

While working on a live website upgrade, I'm facing the same issue.
My schema version is currently 7301. It looks like Panels needs to use the panels_simple_cache_clear_cache() function during the update 7302. As this function now relies on the cache_panels cache bin it leads to an error.

As we are using CI to deploy our work it's really annoying to be locked in that kind of things. The only workaround I found is to create a hook_update_N() in our profile/feature, that creates the cache table and that runs before panels_update_7302() according to a hook_update_dependencies() implementation.

I don't know if it is a clean way to fix that issue but I suppose we could add a call at the beginning of the panels_update_7302() to create the cache table. Given the content of panels_update_7301() and panels_update_7300() it shouldn't be necessary to do the same there.
The attached patch is really simple and solves the issue. I'll let you argue about it's quality ;)

It wasn't included in 3.6 so maybe we can get it into 3.7.

The patch here will conflict with #2786073: "Unknown column 'storage_type'" when updating from v3.3 to v3.6 - one of these will need to be re-rolled after the other is committed.

This is fixed.. for now. However, we may need to address the core issue that is causing this problem, see #2787123: Re-write panels_update_7302() to not call panels_save_display() for more info.