Hi,
I have been asked to write up guidelines that spell out in a deatailed manner the process for merging duplicate records. We currently have four Tessitura users who are allowed to merge and we are looking at expanding the numbers of users so as to take care of a large number of duplicate records.
Does anyone have a documentthat spells out the basics of what to look for when merging that they are willing to share?
If you want to share, you can send directly to me at jhouser@omahaperformingarts.org or just post here.
Thanks, Jacob Houser
For us: When merging accounts, keep the account with the msot recent ticket history because it will wipe out if merged as the deleted constituent. I don't know if this is just a glitch for us or not - hopefully this is useful to others.
Sarah,
The merge process is probably not deleting the ticket history records they may just not be included in the merge process. Any custom or local tables (tables in the database starting with LP_) which have a customer_no column should be added to the merge by modifying LP_CONST_MERGE (http://www.tessituranetwork.com/network/Learning/Tessitura%20Knowledgebase/Constituents/Other/16226.aspx). This procedure is called each time the merge is run both before and after the merge process and can be used to include custom data in the merge as well as change the default merge behavior.
For assistance with modifying this procedure for you needs I would recommend contacting the consulting team at consulting@tessituranetwork.com. Also I suspect some folks on the forum would be willing to share their versions.
Best,
Anna
Anna E. Wessely
Manager Asia Pacific/Senior Application Specialist
Tessitura Network, Inc
+1 888 643 5778 x 308
awessely@tessituranetwork.com
www.tessituranetwork.com
Thank you so much for your advice - we'll fiddle around with the tables & finally be able to fix our merging process!
To save you a few minutes coding - this is a bit of script that we've used to identify orphaned tix hist rows (when we had a problem with our merge script) and re-attach them to their new merged identity.
Should work for anyone, assuming their Merged-id attribute keyword_no is still 6.
Ken
------------------------------------------- script to identify unmerged rows in LT_tkt_HISTselect distinct c.customer_no keep_id, a.customer_no delete_id into #tempfrom lt_tkt_hist ajoin t_customer b on a.customer_no = b.customer_nojoin (select customer_no, key_value , create_dt from tx_cust_keyword where keyword_no = 6) c -- kw 6 should be Merged_id on c.key_value = a.customer_nowhere b.inactive =5
-- select * from #temp
--drop table #temp
/* this bit does the fix, so it's commented out until i want to do it. *//* update lt_tkt_hist set customer_no = b.keep_idfrom lt_tkt_hist a join #temp b on a.customer_no = b.delete_id-- select * from lt_tkt_hist where customer_no in (select delete_id from #temp) *//* select * from t_customer where customer_no in (select delete_id from #temp)order by customer_no */
----------------------------------