A query report running on a recurring schedule always uses the original SQL it was scheduled with, even if the Query SQL is changed for that report.
Steps to reproduce:
* Create a new query report
* Query = Select count(*) as count from <table1name>
(where <table1name> is some table in your connected database)
* Export type HTML
* View the report, choose schedule as CSV
* Schedule with cron string = 0,30 * * * * ?
* Schedule to your own email address
* Every 30 seconds, you will get an email with the count from the query, in my case, the number 5 is the count from <table1name>
* In Administration, reports, select the report
* In the query, change <table1name> to <table2name>, where table2 is some other table with a different number of rows than table1
* Click save
* I expect to get the new count via email, in my case table2 count = 6000, but I keep getting the count = 5.
The current workaround seems to be... delete the scheduled report, and re-schedule it. This is problematic as the number of scheduled reports, and associated schedules, emails, etc, gets larger.
I realize you could call this a feature... "report maintains SQL from when originally scheduled, allowing the current SQL and the as-scheduled SQL to differ".
But this is not so great for several reasons:
1. Most SQL changes will be either feature additions or bug fixes, so scheduled reports will be either out-of-date or still contain the old bug until deleted and re-scheduled;
2. The count when you view the report is now different (updated) from the count when emailed (not updated).
3. There is now way to view the original as-scheduled SQL. So it is now different from the current SQL, but it's not easy to see where it differs.