Merge aborted! Reason: Constituent activity took place

Hello friends! 

Has anyone on RAMP been able to remove this as a fail reason? It seems like it would be simple enough by altering AP_MERGE_CUSTOMER to comment out that section of the procedure. But I really hate the idea of altering a standard procedure. Any other ideas? Could I somehow override it in LP_MERGE_CUSTOMER?

Thanks!

Parents
  • Proceed with caution, since in theory it's a useful warning, but hypothetically you could create a wrapper proc that sets the create_dt on all scheduled merges in T_POTENTIAL_DUPS to the current time and then calls AP_MERGE_CUSTOMER2. This should avoid that constituent activity warning on all scheduled merges since the create_dt and last_update_dt are now later than any constituent activity. If the constituent record changes while your merge is running, then you'll see this error again but for good reason.

    Using a wrapper proc leaves the canned code alone. I have custom code in place that does this for my consortium and it works just fine.

    Good luck!

Reply
  • Proceed with caution, since in theory it's a useful warning, but hypothetically you could create a wrapper proc that sets the create_dt on all scheduled merges in T_POTENTIAL_DUPS to the current time and then calls AP_MERGE_CUSTOMER2. This should avoid that constituent activity warning on all scheduled merges since the create_dt and last_update_dt are now later than any constituent activity. If the constituent record changes while your merge is running, then you'll see this error again but for good reason.

    Using a wrapper proc leaves the canned code alone. I have custom code in place that does this for my consortium and it works just fine.

    Good luck!

Children
  • +1 for using a wrapping procedure; 100% agree, do not mess with standard procedures and wrap it up if you need something different.  In fact, Tessitura has provided LP_CONST_MERGE for exactly this purpose.  It has been a long time since that procedure was in its original state in our database, but I believe it does nothing out of the box, but is designed to be customized for special merge rules and actions for your needs, either pre- or post-merge.

    John

  • Yes, LP_CONST_MERGE is great for dealing with specific actions on a single merge. Because it works one at a time on each merge, it can slow down processing, so if you want make changes to all scheduled merges en masse, a wrapping proc that calls AP_MERGE_CUSTOMER2 (which then calls AP_MERGE_CUSTOMER and then LP_CONST_MERGE) will be the most efficient solution. It all depends on your needs and comfort level, but it's nice to have different options!

  • Of course, you are absolutely correct.  It just has been so long since we did not have at least one or two minor custom things that needed to happen on pretty much every merge that I forget that some organizations do not have that.  Slight smile

    Options indeed!