Answers.Body: <p>It sounds like you imported the <code>first_name</code> and <code>last_name</code> values - but the value at the top of the record is the <code>display_name</code>.  You have two options:</p>
  
  <ul>
  <li>Use your SQL script to update the <code>display_name</code> accordingly.</li>
  <li>Export ONLY the <code>contact_id</code> of the affected records (or all records).  Reimport the contact ID via the "Import Contacts" functionality.  All records will be resaved when you import the contact ID and the <code>display_name</code> is recalculated on save.</li>
  </ul>
  
  <p>Incidentally, this is a good if fairly harmless example of why directly updating the database via SQL is usually a bad idea.  If this were imported via the API, the display name would have been recalculated.  In this case, there was no data loss - but if you had tried updating, e.g. donation amounts, the lack of corresponding changes to your line item and financial transaction tables would be difficult to recover from!</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-11-03T19:12:29.897Z
Answers.Text: Thank you! This is great information to have. I'll look into the API more since i have some regular updating I need to do from an outside source. Since I'm used to dealing with databases directly I figured I'd do it this way so it's great to know the consequences of this and learn more about how all the pieces fit together. I really appreciate the information.
Answers.UserDisplayName: Matt Woodward
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-11-03T18:47:12.693Z
Answers.LastActivityDate: 2018-11-03T18:47:12.693Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Body: <p>I'm finishing up a migration to CiviCRM from a homegrown Python application I wrote, and without going into too much detail as to the why, I needed to do a bulk update of all the contact name fields in the civicrm_contact table using a spreadsheet dump from the old application.</p>
  
  <p>I wrote a script that loops over the rows in the spreadsheet and runs an update statement on each record in civicrm_contact table using the external_identifier field to match.</p>
  
  <p>This all seems to have run fine, but when I go to the contact in CiviCRM the old values are still there. However, when I click at the top of the contact screen to put the name fields into edit mode, the new values are in the form fields, and when I hit save the new values appear.</p>
  
  <p>Is there some caching going on such that this will fix itself, or does updating the name fields directly as I did have some other implications/consequences I should be aware of? Thanks.</p>
  
Tags: <contacts><database><sql>
Title: Ran direct SQL update to bulk update contact names, changes not appearing until editing and saving
ThreadText: # Ran direct SQL update to bulk update contact names, changes not appearing until editing and saving
  
  (Asked by: username_0 on 2018-11-03)
  
  I'm finishing up a migration to CiviCRM from a homegrown Python application I wrote, and without going into too much detail as to the why, I needed to do a bulk update of all the contact name fields in the civicrm\_contact table using a spreadsheet dump from the old application.
  
  I wrote a script that loops over the rows in the spreadsheet and runs an update statement on each record in civicrm\_contact table using the external\_identifier field to match.
  
  This all seems to have run fine, but when I go to the contact in CiviCRM the old values are still there. However, when I click at the top of the contact screen to put the name fields into edit mode, the new values are in the form fields, and when I hit save the new values appear.
  
  Is there some caching going on such that this will fix itself, or does updating the name fields directly as I did have some other implications/consequences I should be aware of? Thanks.
  
  **Tags:** contacts, database, sql
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-11-03. Score: 6 | Accepted answer
  
  It sounds like you imported the `first_name` and `last_name` values - but the value at the top of the record is the `display_name`. You have two options:
  
  * Use your SQL script to update the `display_name` accordingly.
  * Export ONLY the `contact_id` of the affected records (or all records). Reimport the contact ID via the "Import Contacts" functionality. All records will be resaved when you import the contact ID and the `display_name` is recalculated on save.
  
  Incidentally, this is a good if fairly harmless example of why directly updating the database via SQL is usually a bad idea. If this were imported via the API, the display name would have been recalculated. In this case, there was no data loss - but if you had tried updating, e.g. donation amounts, the lack of corresponding changes to your line item and financial transaction tables would be difficult to recover from!
  
  > **Comments:**
  > **username_0**: Thank you! This is great information to have. I'll look into the API more since i have some regular updating I need to do from an outside source. Since I'm used to dealing with databases directly I figured I'd do it this way so it's great to know the consequences of this and learn more about how all the pieces fit together. I really appreciate the information.  
  
  ---
  
  