That should probably be the other way round?
WHERE UurRegKB.datum BETWEEN date() -30 AND date()
I would aggregate the data as much as possible in SQL - to transfer the MINIMUM number of rows to Excel.
If you don't actually need drill-down of 82,000 records in Excel?? then transfer just the next-level-up summary totals instead.
We don't do it like that here (but I can see that it would work as you describe it).
We use a report writer which runs in a browser. It can display a nice graph, as you describe, but then the user can "click" on something to drill down. The data for the Drill-Down is NOT present, what actually happens for the Drill Down is that parameters are created from what the user clicks on (e.g. a specific Week or User etc.) and then a new SQL query is run to get that data, the data is displayed and then the user can drill-down further on that data, or perhaps instead clicks on something different (in the original Graph) to see a drill down on just that section of data.
This avoids having all 82,000 rows available at any one time. This makes the APP much more scalable - if it was 8,000,000 rows it would not matter - the first query would only return enough (aggregate) rows for the initial graph, then each drill-down would return a small-ish number of rows. Generally the user is only interested in drilling down on things that "look odd" so rarely actually wants ALL the raw data.
Dunno how you would do that with Excel, and maybe not relevant to what you are trying to do, in which case it will just be "food for thought" ...