CiviCRM Community Forums (archive)

Hi,

we have some problems with importing moved contacts. We got a list containing a Civi ID (Internal Contact ID) and columns with old Street, Postal Code, City and the current Street, Postal Code and City (one column for each).
We'd like to instert the old adress with the adress type "old" and the current adress with the adress type "Privat". And the current adress should be tagged as "primary location". Both adress types exist.
To import the list isn't the problem. But Civi always tagged the the old adress as "primary location". 
I tried to import both adresses at the same time. I also tried to import the old adress first and import the old adress afterwards and to import the old adress first and then the current. But in every case the adress type "old" is tagged as "primary location".
I checked the settings and the adress type "Privat" is marked as default.

The import options for duplicate contacts need to be "update", because some contacts have a old adress which needs to be updated and every contact has a current adress, which needs to overwrite.

(Also checked it on the demo version of Civi with the same result I described).

Does anyone know a solution? I imported the current adress now, but we want to save the old adress, too.
Thank you in advance!

Thank you Erik. Unfortunately, I'm just a "normal" user with no access to the database. I will ask our development-team whether they can do this update function you descibed.

Hi Erik!

Hmm sounds like a little bug in the import fuction. Is it an option to update the data in the database directly after the import? You could update the field 'is_primary' in table civicrm_address using the 'location_type_id' ?

You mean like this:
UPDATE civicrm_address SET is_primary=0 WHERE location_type_id = @old;
or like this:
UPDATE civicrm_address SET is_primary=1 WHERE location_type_id = @private;

Both cases raise the question what happens if we produce two or zero address entries for one contact with the is_primary flag set.

We could extend the SQL query to take care of this, but I wonder if this is really the kind of thing we want in CiviCRM. Shouldn't we rather file a bug report?

Cheers,
Björn