When attempting to access "/admin/config" I get the message "The website encountered an unexpected error. Please try again later."

Logs tell me this:
PDOException: SQLSTATE[HY000]: General error: 1 near "SHOW": syntax error: SHOW VARIABLES WHERE variable_name = :name; Array ( [:name] => max_allowed_packet ) in views_data_export_requirements() (line 130 of sites/all/modules/views_data_export/views_data_export.install).

I am on Drupal 7.14 and using an SQLITE database.

I recently migrated from MYSQL database using dbtng_migrator module: http://drupal.org/project/dbtng_migrator

CommentFileSizeAuthor
#4 views_data_export-Fix_Mysql_specific_code-1690438-4.patch2.44 KBben coleman

Comments

dsnoeck’s picture

dsnoeck commented

Same issue with D 7.14 and PostgreSQL.

Side note: I have installed Drupal from the command line with Drush.

jamsilver’s picture

jamsilver commented
Status: Active » Needs work

Hmm, it would appear that the technique we're using to auto-detect what mysql's max_allowed_packet size is not exactly compatible with all versions / alternatives of database backend. This code was added in #1421828: Warn if max allowed packet is too small.

I guess is the 'SHOW VARIABLES' syntax simply is unsupported in PostgreSQL and SQLITE.

At the very least we probably need to pop a try/catch around that line so if the db backend does throw an exception we don't cause a WSOD. Patches welcome!

robertwb’s picture

robertwb commented

Thanks jamsilver - I commented out the offending line in order to get mine to survive the fatal errors, but yours is of course the more corrtrect solution.

r.b.

ben coleman’s picture

ben coleman commented
Title: PDOException: SQLSTATE[HY000]: General error: 1 near "SHOW" » Fix MySQL-specific code in views_data_export_requirements
Priority: Normal » Major
Status: Needs work » Needs review
StatusFileSize
new views_data_export-Fix_Mysql_specific_code-1690438-4.patch2.44 KB

I ran into this after upgrading to the latest -dev on a PostgreSQL-based system. Not only is the SQL code MySQL-specific, the need is MySQL-specific - from what I've been able to find out PostgreSQL doesn't have the problem that this checks for. The attached patch checks the database type and only runs the code if MySQL is being used. I set it up as a switch/case so if there is similar code needed for other database types, there's a place to put it in.

Bumped the priority to major as this kills the status page on PostgreSQL.

tricasse’s picture

tricasse commented
Status: Needs review » Reviewed & tested by the community

Same for a site installed with SQLite from the beginning. The patch in #4 works for me.

steven jones’s picture

steven jones commented
Status: Reviewed & tested by the community » Needs review

Going to get the testbot to review the patch...

steven jones’s picture

steven jones commented
Status: Needs review » Reviewed & tested by the community

Patch looks good.

steven jones’s picture

steven jones commented
Status: Reviewed & tested by the community » Fixed

Thanks so much for the patch, fixed in 7.x-3.x.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.