You data is stored in a SQL database and you have an Access front end that generates a report. Why does there HAVE to be an easy way for a SQL Agent job to execute the report AND email it when this report does not live in SQL?
While related, the two technologies are not identical nor are they fully compatable in this case (at least to my knowledge).
If you want this report to live in Access, you will need to use Access to control the "running and distribution". This is best left to Access, which has the back end coding to handle this. This has been suggested as the database with an autoexec macro to do the work.
There are a couple of SQL options though. Both have advantages and disadvantages.
You can create the report in SQL Server Reporting Services. The downside here is if you don't SSRS already setup. You would need to set it up on your server. If you haven't used it before, you will find that your experience in creating reports in Access will shorten your learning curve. Once the report is created in SSRS, you can then schedule it to run and email itself to whomever you need. This is all built into the SSRS engine. The positives for using SSRS are many in my opion: no more need to have Access JUST for reports, ALL reports can be deployed to the same place and controlled with some simple basic security, caching/pre-rending large reports for performance gains, etc.
Another option that can be use is to have the SQL Agent job run the stored procedure and email the results using dbmail. The downside here is that you get the results as if they were run in SQL Management Studio. Your formatting options are very limited.
Ultimately you will need to decide solution fits your needs, resources, and budget.
=======================================
People think it must be fun to be a super genius, but they don't realize how hard it is to put up with all the idiots in the world. (Calvin from Calvin And Hobbs)
Robert L. Johnson III
CCNA, CCDA, MCSA, CNA, Net+, A+, CHDP
C#.NET Programmer