LP_VALIDATE_CUST_MERGE

HI,

We are looking into customizing this procedure to avoid merging of records are not duplicates. Can somebody shed some light on where this procedure is placed (called within another procedure or something) within Tessitura. This will give us understanding of effects of this procedure run. Thanks for your time and help.

Cheers

Harpreet

Parents Reply
  • So this is the code set that worked on me.  Hope that this helps someone else.  Others may have cleaner and tidier ways to get this done.  Please comment.

    ALTER  PROCEDURE [dbo].[LP_VALIDATE_CUST_MERGE]

    ( @kept_id int,

    @delete_id int

    )

    AS

    Set NoCount On  -- added auto CWR 8/9/2001

    declare @kept_id_count int

    declare @delete_id_count int

    declare @err_msg varchar(MAX)

    -- Check to see if we have a membership for delete_id

    select @delete_id_count = count(*) from vxs_cust_membership

    where customer_no = @delete_id and cur_record = 'Y'

    -- Check to see if we have a membership for kept_id

    select @kept_id_count = count(*) from vxs_cust_membership

    where customer_no = @kept_id and cur_record = 'Y'

    -- Do our test

    If (@kept_id_count >= 1 and @delete_id_count >= 1)

      Begin

    -- Oops both accounts have memberships.

    SET @err_msg = 'Merge not possible: Delete and Kept IDs are both current Members! You must Deactivate one of the memberships.'

    raiserror(@err_msg, 11, 2)

    -- Get ready to Tell calling procedure we found a problem.

    select 1

    -- Return to calling procedure

    return

      End

    -- We made it to the bottom!

    -- Get ready to tell calling procedure All OK 0 = False we don't have a problem

    Select 0

    -- Return to calling procedure

    RETURN

Children
  • Oh, I'd check LP_CONST_MERGE as well, as I see that it also had the old RAISERROR syntax in it.

  • Yep.  I'm seeing the same thing.  Now I'm trying to figure out how to test this.

    The code here in LP_CONST_MERGE looks really old and never updated.  It is making reference to a lt_custom_example table which is empty.

    I'm wondering if this is going to break the actual merges.  Not just the setup phase of declaring who should be merged with whom.  But the actual merges themselves.

    And yes, this looks like it is broken as well.  Thanks, next time I'm in the office I'll take a look at this one as well.  

  • So, LP_VALIDATE_CUST_MERGE is run whenever you try to schedule two customers to merge, and should raise an error if there are any conditions where you don't want someone to be able to schedule a merge (that's the slot for your custom code, apparently you don't let a merge go through if both customers are members).  The text returned by RAISERROR should be descriptive, since it will appear in the Merge Status Report.

    LP_CONST_MERGE has a before and after section:  before is custom code you want to run just before the merge happens (which might include re-checking the same issues you wanted to flag in LP_VALIDATE_CUST_MERGE), and the after section can include custom code to run immediately after the merge.  If either raises an error then the merge is cancelled and any work is undone (i.e. a transaction is rolled back).  Typically this is used to update custom tables where you reference a customer number.

    If you're not using this, all you should need to do is update the RAISERROR call, e.g.

    --RAISERROR 50000 'Error Occured in Localized Procedure'
    RAISERROR(@err_table, 11, 2)

  • Oh, I'll actually go a step further and recommend that you re-run your validation in the "before" block of LP_CONST_MERGE, since I think if anything changes with your keep/delete customer accounts between scheduling and merging, I don't think LP_VALIDATE_CUST_MERGE is run again.  I actually broke out our validation code into a function, and just run that from each procedure.