CiviCRM Community Forums (archive)

*

News:

Have a question about CiviCRM?
Get it answered quickly at the new
CiviCRM Stack Exchange Q+A site
This forum was archived on 25 November 2017. Learn more.
How to get involved.
What to do if you think you've found a bug.



  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Support »
  • Using CiviCRM »
  • Using Core CiviCRM Functions (Moderator: Yashodha Chaku) »
  • Contact merge takes 4 minutes each
Pages: [1]

Author Topic: Contact merge takes 4 minutes each  (Read 958 times)

robinhood

  • I post frequently
  • ***
  • Posts: 153
  • Karma: 6
  • CiviCRM version: 4.5.5
  • CMS version: Drupal 7.34
  • MySQL version: 5.1.56
  • PHP version: 5.3.5
Contact merge takes 4 minutes each
April 18, 2009, 07:35:19 pm
I find that running the "Find and merge duplicate contacts" takes a long time, about 4 minutes, to identify dups.  Is that abnormally long?  Not sure if I have set something up wrong.  We have something like 6,000 contacts.

At any rate I can deal with it, if it only occurs once.  The problem is that we go through the screen to merge contacts, and then click "merge", and then it is another 4 minutes before the Find and Merge list reappears.  I am assuming that the merge itself is not time consuming, but that it is re-running the find queries before it re-displays the list.  If so, it makes dealing with the list very cumbersome. 

If there was a way to stop rerunning the query after the first time so that the identified dups could be dealt with quickly one after another, that would be a big improvement. 

Many thanks.

Donald Lobo

  • Administrator
  • I’m (like) Lobo ;)
  • *****
  • Posts: 15963
  • Karma: 470
    • CiviCRM site
  • CiviCRM version: 4.2+
  • CMS version: Drupal 7, Joomla 2.5+
  • MySQL version: 5.5.x
  • PHP version: 5.4.x
Re: Contact merge takes 4 minutes each
April 18, 2009, 08:41:25 pm

1. can you please file an issue and we'll fix for 2.3 (i suspect the fix is not trivial)

2. an easy way to get around the below is:

* Click on merge so that it appears in another tab

* Edit CRM/Contact/Form/Merge.php and change the last 2 lines

FROM

Code: [Select]
        $url = CRM_Utils_System::url( 'civicrm/admin/dedupefind', "reset=1&action=update&rgid={$this->_rgid}" );
        CRM_Utils_System::redirect($url);

TO

Code: [Select]
        $url = CRM_Utils_System::url( 'civicrm/admin/deduperules', "reset=1" );
        CRM_Utils_System::redirect($url);

This will avoid the expensive computation of the merges and thus reduce load on server

lobo

A new CiviCRM Q&A resource needs YOUR help to get started. Visit our StackExchange proposed site, sign up and vote on 5 questions

robeal

  • Guest
Re: Contact merge takes 4 minutes each
September 30, 2009, 05:52:27 pm
What would I do when running 2.0.7?

Those lines don't exist in Form.php

Donald Lobo

  • Administrator
  • I’m (like) Lobo ;)
  • *****
  • Posts: 15963
  • Karma: 470
    • CiviCRM site
  • CiviCRM version: 4.2+
  • CMS version: Drupal 7, Joomla 2.5+
  • MySQL version: 5.5.x
  • PHP version: 5.4.x
Re: Contact merge takes 4 minutes each
September 30, 2009, 06:10:59 pm

unfortunately we dont support 2.0.x. We would recommend you upgrade to 2.2.x or better yet wait for a day or so and upgrade to 3.0.x (final being released in the next few days)

the dedupe functionality was much improved in 2.1.x

lobo


A new CiviCRM Q&A resource needs YOUR help to get started. Visit our StackExchange proposed site, sign up and vote on 5 questions

robeal

  • Guest
Re: Contact merge takes 4 minutes each
October 01, 2009, 07:26:02 am
That is going to be a tough sell to our client. Is there anything we can hack to make it faster.

How painful will the upgrade be to get from 2.0.7 to 3.0? Would that still work with Drupal 5.x?
Pages: [1]
  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Support »
  • Using CiviCRM »
  • Using Core CiviCRM Functions (Moderator: Yashodha Chaku) »
  • Contact merge takes 4 minutes each

This forum was archived on 2017-11-26.