• Sue_H - Thursday, December 7, 2017 4:08 PM

    pietlinden - Thursday, December 7, 2017 3:32 PM

    This sounds like something you'd want to schedule with a job instead of using a trigger... well, at least to my mostly ignorant way of thinking. Then you could find all Invoices/parent records with updated/new line items (if they're time-stamped), and do e-mail per invoice. Per line item sounds pretty painful.

    I'm sure someone smarter than I will poke holes in my idea, but one e-mail per line item sounds a bit excessive.

    That was what I was thinking as well. Main reason being that I don't like sending emails in triggers.
    But it resolves the issue about all the emails going out. Use the trigger to dump the data to a table, have a processed flag or something like that for the table, have a job poll and send the email, then mark the rows as processed (or delete them but the history would likely be important for at least some time).

    Sue

    That's the way I do such things mostly because it allows me to shut down the email process without having to change the code in the trigger.  It also allows for other exquisite control and validation without have much affect on the instigating process at all.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)