Answers.Body: <p>I ran into a similar problem when manually updating. Depending on how your database is configured the update will fail when trying to change the image_URL from <code>VARCHAR(256)</code> to <code>VARCHAR(512)</code>. I wasn't able to figure out how to get it to let me make the change (it would even fail when I tried to directly manipulate the table). I ended up commenting out this line of the SQL update and everything ran just fine. </p>
  
  <p>If I were you I would just do a manual update of CiviCRM.</p>
  
  <p>You can comment out the SQL line in this file:
  <code>sites/all/modules/civicrm/CRM/Upgrade/Incremental/sql/4.7.8.mysql.tpl</code></p>
  
  <p>Just be sure to backup your DB before doing this.</p>
  
  <pre><code>mysqldump -u user -p mycividb &gt; mycividb-backup.sql
  </code></pre>
  
  <p>I hope this helps!</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-07-14T15:52:25.970Z
Answers.Text: The issue here is character encoding.  If your character encoding is latin1, each character is 1 byte - so you can do VARCHAR(767) and not go over InnoDB's "767 characters per column" limit.  By comparison, UTF8 has a variable number of bytes per character - up to 3 bytes.  So you can't go above VARCHAR(255).
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-07-15T19:05:21.110Z
Answers.Text: That's really good to know. Is it recommended to set the character encoding to latin1? I have always done UTF8_unicode_ci...
Answers.UserDisplayName: Sleewok
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-07-19T00:11:17.930Z
Answers.Text: This doesn't seem like a good idea, since it will leave the database with a schema different from what's expected and could very well fail in the next schema update.
Answers.UserDisplayName: Ken Williams
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-07-19T01:16:41.757Z
Answers.Text: I looked at https://github.com/civicrm/civicrm-core/pull/8605 and they solve it by redefining the `civicrm_contact.index_image_url` index to be length 128.  I'm assuming this is going to make it into version 4.7.10, so this is the solution I went with.
Answers.UserDisplayName: Ken Williams
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-07-14T14:43:41.540Z
Answers.LastActivityDate: 2016-07-19T08:59:34.757Z
Answers.LastEditDate: 2016-07-19T08:59:34.757Z
Answers.UserDisplayName: Sleewok
Body: <p>I'm trying to upgrade from CiviCRM 4.7.4 to 4.7.9 for its security update.  I'm doing this using 'drush' on my dev site.  It seems to be hitting a couple different problems.  Here's the first step:</p>
  
  <pre><code>% drush --version
   Drush Version   :  8.1.2 
  
  % drush -vv cvup --tarfile=~/Downloads/civicrm-4.7.9-drupal.tar.gz
  Executing: mysql --defaults-extra-file=/private/var/tmp/drush_I5s0Cd --database=singersin_drupal --host=localhost --silent  &lt; /private/var/tmp/drush_yqQTCt
  Executing: mysql --defaults-extra-file=/private/var/tmp/drush_Sw9qa5 --database=singersin_drupal --host=localhost --silent  &lt; /private/var/tmp/drush_X3IP5L
  
  The upgrade process involves - 
  1. Backing up current CiviCRM code as =&gt; /Users/ken/Documents/SIA/server275-site/../backup/modules/20160712223432/civicrm
  2. Backing up database as =&gt; /Users/ken/Documents/SIA/server275-site/../backup/modules/20160712223432/civicrm.sql
  3. Unpacking tarfile to =&gt; /Users/ken/Documents/SIA/server275-site/sites/all/modules/
  4. Executing civicrm/upgrade?reset=1 just as a browser would.
  
  Do you really want to continue? (y/n): y
                                                                                                                                                   [ok]
  1. Code backed up.
  Executing: mysql --defaults-extra-file=/private/var/tmp/drush_wbODsK --database=singersin_drupal --host=localhost --silent  &lt; /private/var/tmp/drush_oyC1qd
  Calling system(mysqldump --defaults-extra-file=/private/var/tmp/drush_UDJ4q2  singersin_drupal --host=localhost --no-autocommit --single-transaction --opt -Q  &gt; /Users/ken/Documents/SIA/server275-site/../backup/modules/20160712223432/civicrm.sql);
  Database dump saved to /Users/ken/Documents/SIA/server275-site/../backup/modules/20160712223432/civicrm.sql                                      [success]
  2. Database backed up.                                                                                                                           [ok]
  Undefined variable: tarfile civicrm.drush.inc:368                                                                                                   [notice]
  Executing: gzip -d 
  Executing: tar -xf /Users/ken/Downloads/civicrm-4.7.9-drupal.tar.gz -C "/Users/ken/Documents/SIA/server275-site/sites/all/modules/"
  3. Tarfile unpacked.                                                                                                                             [ok]
  4.                                                                                                                                                  [notice]
  You are already upgraded to CiviCRM 4.7.4
                                                                                                                                                   [completed]
  Process completed.
  Command dispatch complete                                                                                                                           [notice]
  </code></pre>
  
  <p>First, notice the "Undefined variable: tarfile" in the output.  I think that's because of this code in <code>civicrm.drush.inc</code>:</p>
  
  <pre><code>function _civicrm_extract_tarfile($destinationPath, $option = 'tarfile') {
    $tarpath = drush_get_option($option, FALSE);
    if (drush_shell_exec("gzip -d " . $tarfile)) {
      $tarpath = substr($tarfile, 0, strlen($tarfile) - 3);
    }
    drush_shell_exec("tar -xf $tarpath -C \"$destinationPath\"");
  }
  </code></pre>
  
  <p>There are 3 instances of <code>$tarfile</code> that should be <code>$tarpath</code>, right?</p>
  
  <p>The next problem is that it can't recognize the version it's trying to upgrade to - it says "You are already upgraded to CiviCRM 4.7.4", when trying to upgrade to 4.7.9.  I'm guessing that's because the code was originally loaded when 4.7.4 was installed, so it would need to re-load itself somehow to detect that it's out of date.</p>
  
  <p>Okay, no problem, I figured I could just run <code>drush cvupdb</code> separately.  However, this fails with a database error:</p>
  
  <pre><code>% drush cvupdb
  PEAR_Exception: "DB Error: unknown error"
   * ERROR TYPE: DB_Error
   * ERROR CODE: -1
   * ERROR MESSAGE: DB Error: unknown error
   * ERROR MODE: 16
   * ERROR USERINFO: ALTER TABLE `civicrm_contact` CHANGE `image_URL` `image_URL` VARCHAR(512) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL COMMENT
    'optional URL for preferred image (photo, logo, etc.) to display for this contact.'
    [nativecode=1071 ** Specified key was too long; max key length is 767 bytes]
   * ERROR DEBUGINFO: ALTER TABLE `civicrm_contact` CHANGE `image_URL` `image_URL` VARCHAR(512) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL COMMENT
    'optional URL for preferred image (photo, logo, etc.) to display for this contact.'
    [nativecode=1071 ** Specified key was too long; max key length is 767 bytes]
   ...
  </code></pre>
  
  <p>My database is MySQL version 5.6.27, is that problematic?  What's a next step?</p>
  
  <p>Thanks.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-07-14T15:54:08.590Z
Comments.Text: The second issue you're facing is the same one described here: http://civicrm.stackexchange.com/questions/12489/when-upgrading-from-4-7-7-to-4-7-8-i-get-error-specified-key-was-too-long
Comments.UserDisplayName: Jon G - Megaphone Tech
Tags: <drupal><upgrade><error><mysql><drush>
Title: Funky errors in 'drush cvup' / 'drush cvupdb'
ThreadText: # Funky errors in 'drush cvup' / 'drush cvupdb'
  
  (Asked by: username_0 on 2016-07-13)
  
  I'm trying to upgrade from CiviCRM 4.7.4 to 4.7.9 for its security update.  I'm doing this using 'drush' on my dev site.  It seems to be hitting a couple different problems.  Here's the first step:
  % drush --version
   Drush Version   :  8.1.2 
  
  % drush -vv cvup --tarfile=~/Downloads/civicrm-4.7.9-drupal.tar.gz
  Executing: mysql --defaults-extra-file=/private/var/tmp/drush_I5s0Cd --database=singersin_drupal --host=localhost --silent  < /private/var/tmp/drush_yqQTCt
  Executing: mysql --defaults-extra-file=/private/var/tmp/drush_Sw9qa5 --database=singersin_drupal --host=localhost --silent  < /private/var/tmp/drush_X3IP5L
  
  The upgrade process involves - 
  1. Backing up current CiviCRM code as => /Users/ken/Documents/SIA/server275-site/../backup/modules/20160712223432/civicrm
  2. Backing up database as => /Users/ken/Documents/SIA/server275-site/../backup/modules/20160712223432/civicrm.sql
  3. Unpacking tarfile to => /Users/ken/Documents/SIA/server275-site/sites/all/modules/
  4. Executing civicrm/upgrade?reset=1 just as a browser would.
  
  Do you really want to continue? (y/n): y
                                                                                                                                                   [ok]
  1. Code backed up.
  Executing: mysql --defaults-extra-file=/private/var/tmp/drush_wbODsK --database=singersin_drupal --host=localhost --silent  < /private/var/tmp/drush_oyC1qd
  Calling system(mysqldump --defaults-extra-file=/private/var/tmp/drush_UDJ4q2  singersin_drupal --host=localhost --no-autocommit --single-transaction --opt -Q  > /Users/ken/Documents/SIA/server275-site/../backup/modules/20160712223432/civicrm.sql);
  Database dump saved to /Users/ken/Documents/SIA/server275-site/../backup/modules/20160712223432/civicrm.sql                                      [success]
  2. Database backed up.                                                                                                                           [ok]
  Undefined variable: tarfile civicrm.drush.inc:368                                                                                                   [notice]
  Executing: gzip -d 
  Executing: tar -xf /Users/ken/Downloads/civicrm-4.7.9-drupal.tar.gz -C "/Users/ken/Documents/SIA/server275-site/sites/all/modules/"
  3. Tarfile unpacked.                                                                                                                             [ok]
  4.                                                                                                                                                  [notice]
  You are already upgraded to CiviCRM 4.7.4
                                                                                                                                                   [completed]
  Process completed.
  Command dispatch complete                                                                                                                           [notice]
  
  First, notice the "Undefined variable: tarfile" in the output.  I think that's because of this code in civicrm.drush.inc:
  function _civicrm_extract_tarfile($destinationPath, $option = 'tarfile') {
    $tarpath = drush_get_option($option, FALSE);
    if (drush_shell_exec("gzip -d " . $tarfile)) {
      $tarpath = substr($tarfile, 0, strlen($tarfile) - 3);
    }
    drush_shell_exec("tar -xf $tarpath -C \"$destinationPath\"");
  }
  
  There are 3 instances of $tarfile that should be $tarpath, right?
  The next problem is that it can't recognize the version it's trying to upgrade to - it says "You are already upgraded to CiviCRM 4.7.4", when trying to upgrade to 4.7.9.  I'm guessing that's because the code was originally loaded when 4.7.4 was installed, so it would need to re-load itself somehow to detect that it's out of date.
  Okay, no problem, I figured I could just run drush cvupdb separately.  However, this fails with a database error:
  % drush cvupdb
  PEAR_Exception: "DB Error: unknown error"
   * ERROR TYPE: DB_Error
   * ERROR CODE: -1
   * ERROR MESSAGE: DB Error: unknown error
   * ERROR MODE: 16
   * ERROR USERINFO: ALTER TABLE `civicrm_contact` CHANGE `image_URL` `image_URL` VARCHAR(512) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL COMMENT
    'optional URL for preferred image (photo, logo, etc.) to display for this contact.'
    [nativecode=1071 ** Specified key was too long; max key length is 767 bytes]
   * ERROR DEBUGINFO: ALTER TABLE `civicrm_contact` CHANGE `image_URL` `image_URL` VARCHAR(512) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL COMMENT
    'optional URL for preferred image (photo, logo, etc.) to display for this contact.'
    [nativecode=1071 ** Specified key was too long; max key length is 767 bytes]
   ...
  
  My database is MySQL version 5.6.27, is that problematic?  What's a next step?
  Thanks.
  
  **Tags:** drupal, upgrade, error, mysql, drush
  
  > **Comments:**
  > **username_1**: The second issue you're facing is the same one described here: http://civicrm.stackexchange.com/questions/12489/when-upgrading-from-4-7-7-to-4-7-8-i-get-error-specified-key-was-too-long  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2016-07-14. Score: 3 | Accepted answer
  
  I ran into a similar problem when manually updating. Depending on how your database is configured the update will fail when trying to change the image_URL from VARCHAR(256) to VARCHAR(512). I wasn't able to figure out how to get it to let me make the change (it would even fail when I tried to directly manipulate the table). I ended up commenting out this line of the SQL update and everything ran just fine. 
  If I were you I would just do a manual update of CiviCRM.
  You can comment out the SQL line in this file:
  sites/all/modules/civicrm/CRM/Upgrade/Incremental/sql/4.7.8.mysql.tpl
  Just be sure to backup your DB before doing this.
  mysqldump -u user -p mycividb > mycividb-backup.sql
  
  I hope this helps!
  
  > **Comments:**
  > **username_1**: The issue here is character encoding.  If your character encoding is latin1, each character is 1 byte - so you can do VARCHAR(767) and not go over InnoDB's "767 characters per column" limit.  By comparison, UTF8 has a variable number of bytes per character - up to 3 bytes.  So you can't go above VARCHAR(255).  
  > **username_2**: That's really good to know. Is it recommended to set the character encoding to latin1? I have always done UTF8_unicode_ci...  
  > **username_0**: This doesn't seem like a good idea, since it will leave the database with a schema different from what's expected and could very well fail in the next schema update.  
  > **username_0**: I looked at https://github.com/civicrm/civicrm-core/pull/8605 and they solve it by redefining the `civicrm_contact.index_image_url` index to be length 128.  I'm assuming this is going to make it into version 4.7.10, so this is the solution I went with.  
  
  ---
  
  