• Flat out, they're asking for crazy stuff. Even if you can find some type of solution to deliver what's being asked for, it's going to be a Rube Goldberg style solution that isn't going to scale and will certainly be a maintenance nightmare. Better to spend your time getting them on board with the idea that it's all about data. Sure, store that an email was sent and store the parameter values that can recreate the email. Storing the message, and as a .msg file, which will have to be done as a second step because SQL Server on it's own is NOT creating that format, so it has to come from outside SQL Server and cannot possibly be a part of the fundamental service... they're digging a hole.

    A pretty healthy chunk of all the issues around SQL Server, or any other DBMS for that matter, is because people fight tooth & nail to make it do stuff that it just wasn't designed for. I had a fight with a developer once when they presented me with code that wouldn't scale or perform. When I said it violated best practices the developers response, and they considered it absolutely definitive, was "But nothing in SQL Server prevented me from doing this, so it must be how it was supposed to function." Yes, I know how stupid that sounds. Yes, nothing prevents you from hammering your toes flat and yet that's not the intended function of a hammer. Yes, I lost the fight, initially. The code went into the server. It failed, badly. We had to completely redesign the system.

    You're in that same fight. Good luck.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning