Ad-hoc database queries
Reports ::: report_customsql
Maintained by
Tim Hunt,
Mahmoud Kassaei
This report plugin allows Administrators to set up arbitrary database queries
to act as ad-hoc reports. Reports can be of two types, either run on demand,
or scheduled to run automatically. Other users with the right capability can
go in and see a list of queries that they have access to. Results can be viewed
on-screen or downloaded as CSV.
Latest release:
3559 sites
1k downloads
133 fans
This report, created by The Open University, lets Administrators set up arbitrary SQL select queries that anyone with the appropriate permissions can then run. Reports can be set to be runnable on-demand, or automatically run weekly or monthly.
The results are displayed as a fairly plain HTML table, and can also be downloaded as CSV.
The idea is that this lets you quicly set up ad-hoc reports, without having to create a whole new admin report plugin.
Contributors
Tim Hunt (Lead maintainer)
Mahmoud Kassaei: Developer
Please login to view contributors details and/or to contact them
We have been working to debug the issue on our moodle site, during which we have observed the following:
* The timestamp is being turned into a filename in a function called report_customsql_temp_cvs_name in locallib.php, which is called from both the view.php and download.php files.
* view.php is the report view, where you have the option to download the various types of reports.
* download.php is the PHP script that is supposed to return the file or display the error message.
The timestamp is the exact same when the function is called from view.php and download.php, but the filename that is created based on the timestamp is 5 hours different in the view.php instance than the download.php instance, even though it is the same function.
We suspect the download function fails because of the difference in the timestamp.
Any ideas? Your feedback is most welcome.
Paul
Sounds like a time-zone bug in the code. Please re-open the github issue I closed (or create a new one) with the details.
I am busy, so I don't know when I will be able to work on fixing this myself. Pull requests welcome.
What worked for us was to uninstall the plugin and re-install it.
There's a table in the Moodle database called 'mdl_message_providers', and for a plugin to be able to send out a message it needs to have an entry in that table. The site that was not sending scheduled reports had no entry for the report_customsql plugin. We backed up our custom reports, uninstalled the plugin, reinstalled and restored the backed up reports.
When we checked the database that message provider got added to the correct table in the database during the installation process and our daily scheduled reports started getting emailed right on time!
Hope this helps!
In the spirit of sharing,
Sarah
And, might be worth setting Debugging to Developer level, to see if that makes a difference.
But, this is just standard Moodle messaging API. It should work. It does normally.