Answers.Body: <p>So I looked at the civicrm email records of the two contacts that produce such an error and they look fine. </p>
  
  <p>Alan figured out that this is a bug: during the merge process when data is being gathered about both contacts, code is verifying that the value is valid, but it does so after converting it to an option value (i.e. email is "2").</p>
  
  <p>A quick workaround for those struggling with the same issue - remove Preferred Method Email from Contacts. For this client this field is no longer used so we could just: </p>
  
  <pre><code>update civicrm_contact set preferred_communication_method=NULL where preferred_communication_method=2;
  </code></pre>
  
  <p>Merges are working again - phew! </p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-23T00:20:11.743Z
Answers.LastActivityDate: 2019-01-24T02:16:56.727Z
Answers.LastEditDate: 2019-01-24T02:16:56.727Z
Answers.UserDisplayName: KarinG - Semper IT
Answers.Body: <p>For anyone else landing here I was having a similar problem, but my client is actively using the preferred_communication_method in their workflow.</p>
  
  <p>KarinG's answer pointed me in a direction that seems right and definitely works for me, with the issue being that the preferred_communication_method is treated as an <strong>array</strong>, and it looks to me like the error encountered in merging is due to code in the merge process that tries to explode the array and work with it.</p>
  
  <p>This led me via an answer at <a href="https://stackoverflow.com/questions/47266517/civicrm-crm-core-daovalue-separator-how-to-use-it-in-pure-sql">https://stackoverflow.com/questions/47266517/civicrm-crm-core-daovalue-separator-how-to-use-it-in-pure-sql</a>
  to this immediate solution which lets the client keep using the field <strong>and</strong> have merges work correctly:</p>
  
  <pre><code>update civicrm_contact set preferred_communication_method=concat(X'01',2,X'01') where preferred_communication_method=2;
  </code></pre>
  
  <p>-with X'01' being the CRM_Core_DAO::VALUE_SEPARATOR</p>
  
  <p>With this enacted (obviously for all relevant Integer values in addition to 2), all is fine.</p>
  
  <p>Further note: in my case the reason the fields had an integer instead of an array to begin with is a module I have for taking live input from another CRM system.  My next task is to fix this module (which uses the Civi API, not raw SQL) to populate this field with an array as expected.
  Edit: On further research it was my use of the APIv3, which allows entering and will update with a string value, causing the merge problem.  The solution is to ensure passing an array for preferred_communication_method.
  My updated API call is now of the form </p>
  
  <pre><code>$result = civicrm_api3('Contact', 'create', array(
    'contact_type' =&gt; "Individual",
    'id' =&gt; $cid,
    'preferred_communication_method' =&gt; array($pcm),
  ));
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-08-13T23:53:34.797Z
Answers.LastActivityDate: 2019-08-14T00:31:30.690Z
Answers.LastEditDate: 2019-08-14T00:31:30.690Z
Answers.UserDisplayName: AlexT
Body: <p>After upgrading from 4.6.x to 5.7.3 staff is finding that many records can no longer be merged -> error:</p>
  
  <pre><code>#1 /var/www/platform/oursite/sites/all/modules/civicrm/CRM/Utils/Type.php(554): CRM_Core_Error::fatal("One of parameters  (value: Email) is not of the type Integer")
  #2 /var/www/platform/oursite/sites/all/modules/civicrm/CRM/Core/DAO.php(1517): CRM_Utils_Type::validate("Email", "Integer")
  #3 /var/www/platform/oursite/sites/all/modules/civicrm/CRM/Core/DAO.php(1481): CRM_Core_DAO::composeQuery("\n                        SELECT v.label\n 
  </code></pre>
  
Tags: <duplicate-contacts>
Title: Why can I no longer Merge Contact records in 5.7.3?
ThreadText: # Why can I no longer Merge Contact records in 5.7.3?
  
  (Asked by: username_0 on 2019-01-23)
  
  After upgrading from 4.6.x to 5.7.3 staff is finding that many records can no longer be merged -> error:
  #1 /var/www/platform/oursite/sites/all/modules/civicrm/CRM/Utils/Type.php(554): CRM_Core_Error::fatal("One of parameters  (value: Email) is not of the type Integer")
  #2 /var/www/platform/oursite/sites/all/modules/civicrm/CRM/Core/DAO.php(1517): CRM_Utils_Type::validate("Email", "Integer")
  #3 /var/www/platform/oursite/sites/all/modules/civicrm/CRM/Core/DAO.php(1481): CRM_Core_DAO::composeQuery("\n                        SELECT v.label\n
  
  **Tags:** duplicate-contacts
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2019-01-23. Score: 5
  
  So I looked at the civicrm email records of the two contacts that produce such an error and they look fine. 
  Alan figured out that this is a bug: during the merge process when data is being gathered about both contacts, code is verifying that the value is valid, but it does so after converting it to an option value (i.e. email is "2").
  A quick workaround for those struggling with the same issue - remove Preferred Method Email from Contacts. For this client this field is no longer used so we could just: 
  update civicrm_contact set preferred_communication_method=NULL where preferred_communication_method=2;
  
  Merges are working again - phew!
  
  
  ---
  
  ### Answer by username_1 on 2019-08-13. Score: 1
  
  For anyone else landing here I was having a similar problem, but my client is actively using the preferred_communication_method in their workflow.
  KarinG's answer pointed me in a direction that seems right and definitely works for me, with the issue being that the preferred_communication_method is treated as an array, and it looks to me like the error encountered in merging is due to code in the merge process that tries to explode the array and work with it.
  This led me via an answer at https://stackoverflow.com/questions/47266517/civicrm-crm-core-daovalue-separator-how-to-use-it-in-pure-sql
  to this immediate solution which lets the client keep using the field and have merges work correctly:
  update civicrm_contact set preferred_communication_method=concat(X'01',2,X'01') where preferred_communication_method=2;
  
  -with X'01' being the CRM_Core_DAO::VALUE_SEPARATOR
  With this enacted (obviously for all relevant Integer values in addition to 2), all is fine.
  Further note: in my case the reason the fields had an integer instead of an array to begin with is a module I have for taking live input from another CRM system.  My next task is to fix this module (which uses the Civi API, not raw SQL) to populate this field with an array as expected.
  Edit: On further research it was my use of the APIv3, which allows entering and will update with a string value, causing the merge problem.  The solution is to ensure passing an array for preferred_communication_method.
  My updated API call is now of the form 
  $result = civicrm_api3('Contact', 'create', array(
    'contact_type' => "Individual",
    'id' => $cid,
    'preferred_communication_method' => array($pcm),
  ));
  
  
  ---
  
  