I am using the module on a clean install of 4.7 final. When I enable the module the database tables are not created via the .install script and, accordingly, I get all types of errors about certain tables not existing.

CommentFileSizeAuthor
#6 amazon_2.install6.12 KBPrometheus6

Comments

Prometheus6’s picture

Details? Operating system, PHP version, database type?

bryansd’s picture

For a fresh install...I don't even see the files amazon.mysql (MySQL) or amazon.pgsql (PostgreSQL). Are they missing or am I just looking in the wrong place?

eaton’s picture

Under Drupal 4.7, the database installation is handled by the .install file.

Prometheus6’s picture

I just did a clean install of 4.7 and enabled the module with no problem. From what you've given, that's all I can do.

Tiburón’s picture

Hi,

I have trouble getting Amazontools to work under Drupal 4.7 too.

My host is using:

  • PHP - 5.1.2
  • MySQL - 5.0.18
  • phpMyAdmin - 2.8.0.3

The version of the install script:

// $Id: amazon.install,v 1.7 2006/04/06 23:35:11 prometheus6 Exp $

This is the error I got in Drupal when first activating the modul (I have only changed the installpath listed last):

user warning: Specified key was too long; max key length is 1000 bytes query: CREATE TABLE amazonitem ( asin varchar(10) NOT NULL default '', detailpageurl text, smallimageurl varchar(255) default NULL, smallimageheight int(10) default NULL, smallimagewidth int(10) default NULL, mediumimageurl varchar(255) default NULL, mediumimageheight int(10) default NULL, mediumimagewidth int(10) default NULL, largeimageurl varchar(255) default NULL, largeimageheight int(10) default NULL, largeimagewidth int(10) default NULL, author varchar(255) default NULL, editorialreview longtext, binding varchar(100) default NULL, listamount int(10) default NULL, listcurrencycode char(3) default NULL, listformattedprice varchar(10) default NULL, title varchar(100) default NULL, amount int(10) default NULL, currencycode char(3) default NULL, formattedprice varchar(10) default NULL, availability varchar(50) default NULL, pricedate datetime default NULL, PRIMARY KEY (asin), KEY Title (title), KEY Author (author,title) ) /*!40100 DEFAULT CHARACTER SET utf8 */ in /home/serveruser/siteroot/includes/database.mysql.inc on line 120.

Not that easy to read with no linefeeds, but notice the message "Specified key was too long; max key length is 1000 bytes". It will show it's head again below.

Checking the database with phpMyAdmin revealed that the table amazonitem was not created but amazonnode was.

I tried to run the SQL statement for creating the amazonitem table in phpMyAdmin but got the same result, same error message.

I removed the "DEFAULT CHARACTER SET utf8" bit and tried again. This time the table got created but was using latin1 not utf8.

I manually started to change the latin1 fields to utf8 one by one, and I managed to get all but one row changed:

Error:

SQL-query:

ALTER TABLE `amazonitem` CHANGE `title` `title` VARCHAR( 100 ) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL

MySQL returned: Documentation
#1071 - Specified key was too long; max key length is 1000 bytes 

I hope this info can help you find a solution...

Regards,

Christian Larsen

Prometheus6’s picture

StatusFileSize
new6.12 KB

Okay, that did it.

The problem is an index. Now that we're all utf-8, a character can be more than one byte in size, so the author index is now bigger than MySQL will support. Since the index was just there "in case," I'm dropping it.

I'm attaching the new install file. Since you've already installed it once, there's a record in the system table that must go to get a fresh start.

delete from system where name='amazon'

Drop the old tables and you should be okay.

Prometheus6’s picture

Assigned: Unassigned » Prometheus6
Status: Active » Fixed
Tiburón’s picture

Great,

I cleaned the database, replaced the amazon.install file, went to the modules page and activated amazontools.

No errors this time :-)

I have checked the database, and the tables are listed as utf8 encoded.

Thank you for the quick response, and the extra info about the cause of the problem.

Regards,

Christian Larsen

bryansd’s picture

Also thanks to Tiburon for posting the details to the problem. I was a little too busy to throw anything more than simple "me too".

-Bryan

Prometheus6’s picture

Agreed. With that level of detail not only was it quick to find, I felt I had no choice! ;-)

Prometheus6’s picture

Status: Fixed » Closed (fixed)
greg.harvey’s picture

Good explanation here, for anyone chasing a similar issue:
http://www.calivia.com/blog/mike/mysql-innodb-specified-key-was-too-long...