We have the AP_MERGE_CUSTOMER2 stored proc scheduled to run every Tues/Thurs/Sat at 3am. We're finding that we are getting a lot of failed merges and I've been able to track it down to last_activity_dt on either the kept or deleted file being changed between the time of the merge being scheduled and the above stored proc running.
The majority of the failed merges seem to be when either the keep or delete file involves a file with a membership record on it. We have the membership update utility scheduled to run daily between 7-9am and it seems that this utility is changing the last_activity_dt on these records, even though it doesn't actually change anything on the customer file.
Has anyone come across this or have you altered the merge procedure to ignore membership records to bypass this last_activity_dt? Any advise would be appreciated.
Michele,
It sounds like you're experiencing defect number 68047 in V12.5.1: "In Reports and Utilities, when running the Membership Update Utility, Last Activity Date was being updated for constituents whose memberships were updated in previous runs of the utility. Now, only constituents whose memberships are updated in the current run of the utility will have their Last Activity Date updated."
The full list of Reported Defects can be found here.
This is fixed in hotfix 21 (v1251HF21). Make sure you have v1251FH12 installed first as that is a requirement.Dale
Awesome. Thanks so much Dale! We will look at implementing this right away.
Michele