Hi,

i am trying to set up website based on new commerce module but after i migrate website on web server i get this notice on about every page that include view: Notice: unserialize() [function.unserialize]: Error at offset 5801 of 8793 bytes in views_db_object->load_row() (line 1959 of .../public_html/sites/all/modules/views/includes/view.inc).

view is shown so it is not SO big deal but on order display page (example: www.example.com/user/1/orders/17) view is NOT shown and i get this:

Notice: unserialize() [function.unserialize]: Error at offset 5801 of 8793 bytes in views_db_object->load_row() (line 1959 of /home/pizzamal/public_html/sites/all/modules/views/includes/view.inc).
Notice: Undefined property: views_plugin_query_default::$fields in views_plugin_query_default->query() (line 1142 of /home/pizzamal/public_html/sites/all/modules/views/plugins/views_plugin_query_default.inc).
Warning: Invalid argument supplied for foreach() in views_plugin_query_default->compile_fields() (line 1060 of /home/pizzamal/public_html/sites/all/modules/views/plugins/views_plugin_query_default.inc).
Notice: Undefined property: views_plugin_query_default::$fields in views_plugin_query_default->query() (line 1142 of /home/pizzamal/public_html/sites/all/modules/views/plugins/views_plugin_query_default.inc).
Warning: Invalid argument supplied for foreach() in views_plugin_query_default->query() (line 1144 of /home/pizzamal/public_html/sites/all/modules/views/plugins/views_plugin_query_default.inc).
Warning: Invalid argument supplied for foreach() in views_plugin_query_default->compile_fields() (line 1060 of /home/pizzamal/public_html/sites/all/modules/views/plugins/views_plugin_query_default.inc).

Debug:
'Exception: SQLSTATE[42000]: Syntax error or access violation: 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 \'FROM
commerce_line_item commerce_line_item
LIMIT 10 OFFSET 0\' at line 1'
in views_plugin_query_default->execute() (line 1362 of /home/pizzamal/public_html/sites/all/modules/views/plugins/views_plugin_query_default.inc).

As i sad, on my local host web site works just fine.

Is this Views or Commerce related?
Anyone had similar problem?
Any advice on how to resolve?

Comments

bojanz’s picture

bojanz commented

Looks like you didn't move the database correctly, the data got damaged.
Not sure what Views can do in this case (and it's definitely not Commerce related)

dawehner’s picture

dawehner
Primary language German
commented

So please migrate it again to your webserver.

Just a assumption, if you use phpmyadmin. Better use some modules like backup and migrate. They work much better
and don't have such many problems with big databases as phpmyadmin.

sheba’s picture

sheba commented

Thanks for help.

It is true that i had trouble with database during migration (i was using backup & migrate). I had this strange issue: character def for my database was changed from utf8-general_ci to latin1_sweden_ci...

I guesed that Drupal 7, backup & migrate, commerce, Views 3 etc. are not stable enough yet and that stable version will polish this kind of problem... Anyhow i filled bug report on "backup and migrate" and find out there that this happened to some one else and find this solution. A script that changes char definition for all fields:

// your connection
mysql_connect("localhost","user","pass");
mysql_select_db("database");

// convert code
$res = mysql_query("SHOW TABLES");
while ($row = mysql_fetch_array($res))
{
    foreach ($row as $key => $table)
    {
        mysql_query("ALTER TABLE " . $table . " CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci");
        echo $key . " =&gt; " . $table . " CONVERTED<br />";
    }
}

This script changed back my field definiton to utf8_general_ci and my special character worked normally again.

If there is way to fix this error without restoring old database to server database that would be great. (client did some manual data import and I have continued development (final tuning) for week or more...)
If not, i'll had to look deeper into backup & migrate problem that i had and try to avoid character def changing.

jpontani’s picture

jpontani commented

We just did the same thing with our site, and had the same errors on a lot of views.

The issue (for us) was that we changed data in a MySQL dump (plain text file), and then reimported that modified dump back into a new DB. When that happens, the serialization of the view was changed, and broke the view. We changed '/sites/default' to '/sites/main', and since part of the data stored with a serialization is string length, ours broke since the string length changed but the serialization length was still purporting to be the old length.

A quick change of the views forced a reserialization to be saved, and thus got rid of our errors.

Not sure if this is what happened to you, but it's something you might want to look in to.

dawehner’s picture

dawehner
Primary language German
commented

In general the serialization can't be changed. A views object has a lot of different kind of stuff which can't be predicted when generating a table structure.

In general a search and replace in a database dump is not recommended from my perspective. Better write some sql to change things in specific tables.

sheba’s picture

sheba commented

Hi,

First i have upgrade ctool, comerce, views and date to most recent DEV relese than I did some manual data cleanup in database - clear cash_cash table, some orders and user was not properly deleted so i delete them manualy...
Anyhow, after that i have find view that trow an error and revert it. (i never changed that view but it was different than default that commerce module creates)

This did trick for me!
Thanks for help.

sheba’s picture

sheba commented
Status: Active » Closed (fixed)
davidinnes’s picture

davidinnes commented

I ran into the same error, repeatedly, trying to upload a database I'd created on my development server with Drush. ("drush sql-dump.")

I finally thought to use, er, the Backup and Migrate module to dump the database on my development server. Using the Backup and Migrate restore feature on the client's site worked like a charm.

Would it be nice if Drush output something the module would accept? Yes. Would it be even nicer if the module would accept Drush output? That too. In the meantime, using the module on both sides works nicely. (I'm not positive it's necessary but extra credit for using the same version of the module.)