I might still be missing something, but I would flip-flop it: populate the Employee and Date Ranges in .NET (via query, stored procedure, or C# object). You can then pass either the filters to the report to query the DB or possibly directly bind the C# objects. Disclaimer, I haven't done the latter, so don't know the challenges there.
I would keep the separation of concerns and modularity, meaning, let the report handle reporting. Let the app handle "app-ing." If you have such a load that a few more queries is going to cause performance problems, then maybe a more robust (i.e. paid) reporting system is needed. Don't get me wrong, I am all for performance as long as it doesn't sacrifice complexity, modularity, maintainability, etc.
The Kernel