Careful Coding Considerations

I'm pretty sure this stored procedure is fairly vanilla, with some minor adjustments made over the years, but it's been requested that we remove the error that gets raised when activity has taken place in a record since it appeared in the potential dupes table.  The relevant - or what I believe is relevant - code block says:

---------------------------------  CODE BLOCK STARTS HERE  -------------------------------------

--If any change has taken place to either record since they were entered into the t_potential_dups
--table, log exception and skip.

--First check if this pair is coming from t_potential_dups table or manually picked
--RW #4094, added identify_method to manually added criteria

if substring(@criterion, 1, 10) = '!@#$CUSTOM' or @identify_method in (-1,-2) GOTO StartMerging

declare @last_activity_dt datetime
declare @dupTable_dt datetime

select @last_activity_dt = last_activity_dt
from [dbo].t_customer
where customer_no = @original_no

select @dupTable_dt = last_update_dt
from [dbo].t_potential_dups
where customer_no = @original_no

If @duptable_dt IS null or @last_activity_dt > @dupTable_dt
Raiserror('Merge aborted! Reason: Constituent activity took place on kept customer_no %d since this was scheduled for merging.', 11, 2, @original_no)

select @last_activity_dt = last_activity_dt
from [dbo].t_customer
where customer_no = @duplicate_no

select @dupTable_dt = last_update_dt
from [dbo].t_potential_dups
where customer_no = @duplicate_no

If @duptable_dt IS null or @last_activity_dt > @dupTable_dt
Raiserror('Merge aborted! Reason: Constituent activity took place on deleted customer_no %d since this was scheduled for merging.', 11, 2, @duplicate_no)

---------------------------------  CODE BLOCK ENDS HERE  -------------------------------------

Now, am I correct in assuming that the If statements regarding activity dates, and the subsequent Raiserror statements that follow them, can be commented out and that's that? I'm also assuming that the select statements that follow the Raiserror statements will run regardless of the If statements' logic since there is no BEGIN and END statements to make them a block contingent upon the preceding If statement. Or do I need to comment out the entire block from one If statement to the next? Am I making sense?

Thanks, Tessiturians

Parents
  • Hi, Matt--

    We commented out this code (from AP_MERGE_CUSTOMER) here, years ago. This whole block, from "if any change..." to the second "If @duptable_dt IS null..." is commented out, approximately lines 270-300.

    YMMV, but I think you'll enjoy the change.

  • Thank you both, Chris and Paul, I think I've got it sorted now.

    On a related note, when I run the Identify Duplicates job (which runs AP_IDENTIFY_DUPLICATES), I get an error regarding a primary key violation. When I run the constituent search in Tessitura on the exact customer_no in question, I get the same record as a result twice. WTH? Is there something that can cause Tessitura to "see" a record twice, and therefore try to mark it as a potential dupe with another record more than once, causing an in inevitable crash?

    Thanks, Tessiturians.

Reply
  • Thank you both, Chris and Paul, I think I've got it sorted now.

    On a related note, when I run the Identify Duplicates job (which runs AP_IDENTIFY_DUPLICATES), I get an error regarding a primary key violation. When I run the constituent search in Tessitura on the exact customer_no in question, I get the same record as a result twice. WTH? Is there something that can cause Tessitura to "see" a record twice, and therefore try to mark it as a potential dupe with another record more than once, causing an in inevitable crash?

    Thanks, Tessiturians.

Children