Ok. I've discovered how to get this error to happen on a test shop, so for anyone who is using database-based caching and having the following errors:
Warning: Variable passed to each() is not an array or object in ... ...and/or:
Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at ...
Warning: Cannot modify header information - headers already sent by (output started at ...
1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'EXPECTED_PRODUCTS_SORT limit MAX_DISPLAY
in:
[select p.products_id, pd.products_name, products_date_available as date_expected from products p, products_description pd where p.products_id = pd.products_id and p.products_status = 1 and pd.language_id = '1' and p.products_date_available >=20070313 order by EXPECTED_PRODUCTS_FIELD EXPECTED_PRODUCTS_SORT limit MAX_DISPLAY_UPCOMING_PRODUCTS]when they install more than a few (typically 5+) Royal Mail modules in their shop, the following (hopefully) will explain what's happening, and why the SQL fix hasn't seemed to work.
As Philip said in his bug report (see post #279 above) the above errors are being caused by the cache_data field in the db_cache table (in the database) not being big enough out-of-the-box to hold the increased data that the Royal Mail module(s) adds - each module adds a load of zone and shipping rate parameters, so the more modules you add, the bigger the stored data becomes until the storage capacity of the cache_data field is exceeded and the data that the shop is attempting to store there becomes corrupted.
As Philip has said, typically your shop will be fine the first time you access it after installing the RM modules (or after enabling more of them in admin) as the parameters are read from the various tables in the database and stored for the first time in the db_cache table) but subsequent visits will give the error (when the corrupted cached data is then read from the db_cache table).
The solution (again as Philip has said) is to either increase the size of that field from 'blob' to 'mediumblob' - either by editing the structure of the field in the db_cache table, or by running the SQL:
ALTER TABLE db_cache CHANGE COLUMN cache_data cache_data MEDIUMBLOB NOT NULL
```or, alternatively, to change to file-based caching (in your configure.php files) so the db_cache table isn't used.
For those people who've already run the SQL to increase the field size to 'mediumblob' and still have the errors, this is is important step that's been missed so far:
** The db_cache table is still holding corrupted data** - so even after you've ran the SQL, the corrupted data is still in the db_cache table and is being retrieved by the shop, and hence the errors still appear. You need to delete the row of cached data in the db_cache table.
You can delete the row either by editing the db_cache table directly with PHPMyAdmin - it will typically look like this:
```php
cache_entry_name cache_data cache_entry_created
zc_cc21d2f64edffccfe06d12dd3327... (might appear blank) 1173818124
```( delete the table row beginning 'zc_...')
or by changing (temporarily) to file-based caching by editing your includes/configure.php and admin/includes/configure.php and changing:
```php
define('SQL_CACHE_METHOD', 'database');
```to
```php
define('SQL_CACHE_METHOD', 'file');
```Then save both configure.php files and access your shop - the error should disappear. If you wish, you can then change both configure.php entries back to 'database' - providing you've first run the SQL, of course.
If you change to file-based caching, check you have the correct path to your cache folder set in admin->configuration->sessions->session directory - it should look something like (your path will probably differ):
> /home/your server user name/public_html/cache@theflyingbeard (and anyone else who tried it): Apologies for giving you duff info in my post above (post #281) on what to change in your configure files - I was thinking of 'sessions' when I should have been thinking of 'cache'.
