CiviCRM Community Forums (archive)

I have got a workaround below.  The additional 128 activity rows might have been caused by sending multiple test messages before the real thing.  The SQL removes the rows from the activity_target table. I know of no side effects.

You should run this SQL before starting the upgrade.

CREATE TEMPORARY TABLE `civicrm_activity_keep` ( id int(10) unsigned, key k  (id)   ) ENGINE MEMORY ;
insert into civicrm_activity_keep(select max(cat.activity_id) from civicrm_activity ca inner join civicrm_activity_target cat on ca.id = cat.activity_id where ca.activity_type_id = 3  group by source_record_id, target_contact_id) ;
delete from civicrm_activity_target where activity_id not in (select id from civicrm_activity_keep);

When I run the sql I get:

mysql> CREATE TEMPORARY TABLE `civicrm_activity_keep` ( id int(10) unsigned, key k  (id)   ) ENGINE MEMORY ;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into civicrm_activity_keep(select max(cat.activity_id) from civicrm_activity ca inner join civicrm_activity_target cat on ca.id = cat.activity_id where ca.activity_type_id = 3  group by source_record_id, target_contact_id) ;
Query OK, 208829 rows affected (4.45 sec)
Records: 208829  Duplicates: 0  Warnings: 0

mysql> delete from civicrm_activity_target where activity_id not in (select id from civicrm_activity_keep);
Query OK, 128 rows affected (0.98 sec)

John