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
  • Actually, it appears to be the same record, just showing up twice in the search results. O_o

     

    Matt Gonzales

    Database Administrator          

    510 Preston St. | Houston | TX 77002

    T: 713-980-8702

    E: mgonzales@hgo.org

    http://www.houstongrandopera.org/images/HGO-Logo.jpg

    Click here to view our website.

    Facebook - Houston Grand Opera Twitter - HouGrandOpera YouTube - HGOpera


    This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. The integrity and security of this message cannot be guaranteed on the Internet.

    http://www.houstongrandopera.org/images/HGO_CampaignLogo_full.png

    From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Paul Kappel
    Sent: Thursday, November 06, 2014 12:59 PM
    To: Matt Gonzales
    Subject: Re: [Tessitura Technical Forum] Careful Coding Considerations

     

    That's terrifying- I would definitely try to delete one of those rows in T_CUSTOMER

    From: Matt Gonzales <bounce-mattgonzales9808@tessituranetwork.com>
    Sent: 11/6/2014 12:54:44 PM

    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.




    This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!

Reply
  • Actually, it appears to be the same record, just showing up twice in the search results. O_o

     

    Matt Gonzales

    Database Administrator          

    510 Preston St. | Houston | TX 77002

    T: 713-980-8702

    E: mgonzales@hgo.org

    http://www.houstongrandopera.org/images/HGO-Logo.jpg

    Click here to view our website.

    Facebook - Houston Grand Opera Twitter - HouGrandOpera YouTube - HGOpera


    This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. The integrity and security of this message cannot be guaranteed on the Internet.

    http://www.houstongrandopera.org/images/HGO_CampaignLogo_full.png

    From: Tessitura Technical Forum [mailto:forums-technical@tessituranetwork.com] On Behalf Of Paul Kappel
    Sent: Thursday, November 06, 2014 12:59 PM
    To: Matt Gonzales
    Subject: Re: [Tessitura Technical Forum] Careful Coding Considerations

     

    That's terrifying- I would definitely try to delete one of those rows in T_CUSTOMER

    From: Matt Gonzales <bounce-mattgonzales9808@tessituranetwork.com>
    Sent: 11/6/2014 12:54:44 PM

    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.




    This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Technical Forum. You may reply to this message to post to the Technical forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!

Children
No Data