Answers.Body: <p>First the available countries and states/provinces need to be defined in the Localization settings.</p>
  
  <p>If you cannot do the SQL query, you can see the available values by creating an address manually and seeing the available values.</p>
  
  <p>The import allows state abbreviations for at least the United States. (e.g. Arizona - AZ).  I use the abbreviations when I do contact imports (I import a lot of contacts).</p>
  
  <p>The city field is not validated against a list of valid values.  So a dual city would work but is not practical.  You should clean up the import data and have 2 addresses for those that need them as Young suggested.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-05-20T11:48:19.947Z
Answers.LastActivityDate: 2017-05-20T11:48:19.947Z
Answers.UserDisplayName: Ron Gridley
Answers.Body: <p>You should note the exceptions for the contacts with dual residences and manually remove their secondary residence, and only keep their primary residence in the sheet. You can always create their secondary residence address within CiviCRM after the import wizard finishes as a non-primary address.</p>
  
  <p>For State/Province names and Country name mismatches, you can create a simple MySQL query for each country that has an issue to get the exact spelling that CiviCRM expects in the import process</p>
  
  <pre><code>use my_civicrm_db_name_here;
  select c.id, c.name as country , sp.id as state_province_id, sp.name as state_province_name from civicrm_country as c left join civicrm_state_province as sp on c.id = sp.country_id where c.name = "Canada"
  </code></pre>
  
  <p>For the list of country names you can simply query the civicrm_country table like so:</p>
  
  <pre><code>use my_civicrm_db_name_here;
  select id, name, iso_code from civicrm_country
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-05-20T08:14:42.780Z
Answers.LastActivityDate: 2017-05-20T08:14:42.780Z
Answers.UserDisplayName: Young-Jin Kim
Body: <p>My first time trying to import CSV data into CiviCRM.  The data looks something like the below (changed to not reveal actual names etc).  The lines in bold are not importing. </p>
  
  <p>I am guessing that in first failure (<strong>Allan Nori</strong>) the city (<strong>Boise /Hiroshima</strong>) and the country (<strong>United States / Japan</strong>) are causing the problem. In the second, probably the state/province (<strong>British Columbia (BC)</strong>). And in the third, the state/province (<strong>Maryland &amp; District of Columbia (DC)</strong>). </p>
  
  <p>For the middle one, I guess I can just eliminate the part in parenthesis (<strong>(BC)</strong>), although it might be nice if the contact would also come up on searches for <strong>BC</strong>. </p>
  
  <p>I'm not sure about the best way to handle the other two. In the first case, the person lives part of the year in Boise, Idaho, and part of the year in Hiroshima, Japan. In the other, Chevy Chase is actually in Maryland, but the person also wants to come up on searches for <strong>District of Columbia</strong> (or <strong>DC</strong>).</p>
  
  <p>Any advice on the best way to handle such situations would be appreciated.</p>
  
  <p>(By the way, these are not all the columns.  I do have email and other data in other columns, but I don't think those are important for this issue.)</p>
  
  <p><a href="https://i.sstatic.net/OmAV9.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/OmAV9.png" alt="enter image description here"></a></p>
  
Tags: <contacts><import><data-import><csv>
Title: How to deal with problem data when importing CSV
ThreadText: # How to deal with problem data when importing CSV
  
  (Asked by: username_0 on 2017-05-20)
  
  My first time trying to import CSV data into CiviCRM. The data looks something like the below (changed to not reveal actual names etc). The lines in bold are not importing.
  
  I am guessing that in first failure (**Allan Nori**) the city (**Boise /Hiroshima**) and the country (**United States / Japan**) are causing the problem. In the second, probably the state/province (**British Columbia (BC)**). And in the third, the state/province (**Maryland & District of Columbia (DC)**).
  
  For the middle one, I guess I can just eliminate the part in parenthesis (**(BC)**), although it might be nice if the contact would also come up on searches for **BC**.
  
  I'm not sure about the best way to handle the other two. In the first case, the person lives part of the year in Boise, Idaho, and part of the year in Hiroshima, Japan. In the other, Chevy Chase is actually in Maryland, but the person also wants to come up on searches for **District of Columbia** (or **DC**).
  
  Any advice on the best way to handle such situations would be appreciated.
  
  (By the way, these are not all the columns. I do have email and other data in other columns, but I don't think those are important for this issue.)
  
  [![enter image description here](https://i.sstatic.net/OmAV9.png)](https://i.sstatic.net/OmAV9.png)
  
  **Tags:** contacts, import, data-import, csv
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2017-05-20. Score: 6 | Accepted answer
  
  You should note the exceptions for the contacts with dual residences and manually remove their secondary residence, and only keep their primary residence in the sheet. You can always create their secondary residence address within CiviCRM after the import wizard finishes as a non-primary address.
  For State/Province names and Country name mismatches, you can create a simple MySQL query for each country that has an issue to get the exact spelling that CiviCRM expects in the import process
  use my_civicrm_db_name_here;
  select c.id, c.name as country , sp.id as state_province_id, sp.name as state_province_name from civicrm_country as c left join civicrm_state_province as sp on c.id = sp.country_id where c.name = "Canada"
  
  For the list of country names you can simply query the civicrm_country table like so:
  use my_civicrm_db_name_here;
  select id, name, iso_code from civicrm_country
  
  
  ---
  
  ### Answer by username_1 on 2017-05-20. Score: 2
  
  First the available countries and states/provinces need to be defined in the Localization settings.
  
  If you cannot do the SQL query, you can see the available values by creating an address manually and seeing the available values.
  
  The import allows state abbreviations for at least the United States. (e.g. Arizona - AZ). I use the abbreviations when I do contact imports (I import a lot of contacts).
  
  The city field is not validated against a list of valid values. So a dual city would work but is not practical. You should clean up the import data and have 2 addresses for those that need them as Young suggested.
  
  
  ---
  
  