Managing Email Distribution Within DB

  • I currently have 2 options for managing changes to email distribution list:

    (1) Open an AR ticket to the NT support team to have them update the Exchange email group

    or

    (2) Manually key in the information in the execute sql task that runs the XP_SENDMAIL proc within my package.  Then ask the DBAs to pick up the latest version of the package.

    Both require the use of other resources and a waiting period.  I'm thinking of transitioning storing the email recipient information for DTS notifications within the database to allow better control of data and am looking for advise on a solution.  An initial thought was to jsut store the info in the database, then query it and dynamically set the @recipient properties on my mailings but was thinking there may be a better more flexible solution out there.

    Any advise would be appreciated (Note:  I must use XP_SENDMAIL, due to DBA restrictions)

     

     

  • I think it depends on how strongly your distribution requirements match those of the Exchange email groups.

    If the groups are set up entirely at your request, then by all means take over the function

    yourself. On the other hand, if you are using pre-existing groups or groups that have been

    set up to meet other or additional needs, then you might want to leave things alone.

    Benefits of storing the email notification info in the database:

     - You eliminate the wait for other resources.

     - You can set up email groups different from the Exchange email groups, if you need to.

     - You can design in your own requirements, such as a backup contact, if you need.

     

    Cons to doing that:

     - When an email contact changes their name (Jane Smith to Jane Jones) or email address,

       they have to notify two groups: Exchange support AND you. Error-prone if they leave you

       out of the loop.

     - When an Exchange group is changed or reorganized for reasons other than DTS notification,

       but that affect a group that you do notify, then you'll have to replicate the

       Exchange changes -- and you may have to set up a notification procedure.  Not a

       really good thing.


    Regards,

    Bob Monahon

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply