Hi Yannis -
A couple of possibilities come to mind.
You could BCC an email address that you can use to keep track of the
notifications sent out. The up side is that you'd have *exactly* what
the subscriber gets. The down side is that it will double the load on
the SMTP server.
Another possibility would be to stream the formatted notification to a
file just prior to handing off to your delivery service. That would
give you the same notification the subscriber gets, but would be
slightly more involved that the first option. In this case the
performance hit would be on the distributor rather than the SMTP
Both of these would require a custom component, but neither should be
very difficult to create.
SQL Server MVP
Get up to speed quickly with SQLNS
I support PASS, the Professional Association for SQL Server.
On Mon, 10 Oct 2005 00:50:03 -0700, "Yannis Pantzis"
<[email protected]> wrote:
>We are currently integrating SQL Notification Services (version 2000 SP1) in
>one of our solutions.
>We have successfully developed the e-mail notifications (SMTP Delivery
>Channel) and the test users receive them normally. We are using digest
>delivery, so as to reduce the number of e-mails the users receive.
>What we would like to do is be able to save (keep, maintain) in some way the
>notifications sent by the application, so that we can have lists of the
>actual notifications messages sent, along with the actual content. E.g., we
>would like to be able to keep the full message (the full formatted body
>content, recipient, date/time, subject) of a (digest) notification that we
>sent to some user a few days ago.
>Some of this information is by default in the database - e.g. which are the
>values of the notification. What we miss are 1) the full generated &
>formatted notification content (since we use digest delivery and it can
>contain multiple notifications in the same e-mail message) and 2) how to
>save this content on the server (e.g. in the database, file, etc.).
>My questions are:
>1. is such functionality available out-of-the-box?
>2. if not, which would be the easiest way to implement it? We thought of
>adding a File Delivery Channel, so that the notification's content is also
>saved in a file that we will then import into the database using e.g. DTS.
>However, the File Delivery Channel only generates plain ASCII whereas we use
>HTML for the existing SMTP Delivery Channel. Building a custom delivery
>channel might be the solution to the problem (as soon as it can store the
>message after being "digested" and fully formatted) but this would mean
>extra development time & cost.
>Any tips are greatly welcome.