Grade scales are stored in the
mdl_scale table, however they are stored as a comma-separated list in the scale column, which makes them quite difficult to query directly from the database. Because the grade is just a number (e.g. 1, 2, 3), it is far more useful to show the corresponding grade scale grade description.
For example, the grade scale might have the following value stored in the scale column (formatted for readability with index):
(1) Mostly separate knowing,
(2) Separate and connected,
(3) Mostly connected knowing
So a final grade of 2 would translate to “Separate and connected” if using this grade scale.
You can use the
substring_index function in MySQL to perform a look up of the corresponding grade scale value (grade description) using the grade value.
Here’s the SQL:
scale, trim(substring_index(substring_index(scale, ',', 2), ',', -1))
from mdl_scale where id = 1;
Simply, replace the index in the inner
substring_index call with the appropriate grade value (e.g. 1, 2, or 3) for this scale and it will give you corresponding grade scale grade description.
If you use a custom user profile field with a date and want to store a date that falls before epoch, 01/01/1970 (e.g. a date of birth), the data will be stored as a negative number
e.g. 20/11/1959 is stored as -319284000 which means 319, 284, 000 seconds BEFORE 01/01/1970.
With MySQL you can convert these with the following SQL which works for both scenarios (before and after epoch, 01/01/1970):
select date_add(from_unixtime(0), interval data second) from mdl_user_info_field
Where in the above “data” is the column that returns the stored user profile field value e.g. date of birth from the mdl_user_info_field record.
If you just want the date (no timestamp):
select date(date_add(from_unixtime(0), interval data second)) from mdl_user_info_field
If you need to debug the SQL generated by any of the $DB methods (DML API), you can use the following around the statement(s) to display the SQL:
The following query provides a summary of the file space usage (in bytes) and number of files used by each course in the system from the
mdl_files meta table for the data directory. This is just for the space used in the data directory (not the database).
c.fullname as course_full_name,
c.shortname as course_short_name,
sum(f.filesize) as size_in_bytes,
sum(case when (f.filesize > 0) then 1 else 0 end) as number_of_files
mdl_files f inner join mdl_context x
on f.contextid = x.id
and x.contextlevel = 50
inner join mdl_course c
on c.id = x.instanceid
It may need some refinement. Context level 50 refers to courses.
The following query gives you an idea of all the moodle blocks that have been added to various pages on your site and where they are positioned:
select bi.*, bp.*, x.*
from mdl_block_instances bi inner join mdl_block_positions bp
on bi.id = bp.blockinstanceid
inner join mdl_context x
on x.id = bp.contextid
order by bi.blockname;
Very handy if you have a block that is causing you problems e.g. not fully uninstalled or visible to users.
The pagetypepattern e.g.
*, site_index, my-index, course-view-* tells you which page types the block will be shown on, while the pagetype gives you the specific instances where it appears.
The context information at the end can also tell you the contextlevel (e.g. 50 = course, 70 = module) and the instance of that context (e.g. x.instanceid = 2 means course id 2 if the contextlevel is 50 (course context).
There is a very handy CLI tool
admin/cli/check_database_schema.php which compares the structure of your Moodle database against the XMLDB metadata and looks for any issues.
These might includes issues such as:
- Missing tables – they exist in XMLDB but not in your DB (not good!)
- Unexpected tables – tables in your database not defined in XMLDB (e.g. created outside of Moodle)
- Mismatches between table column definitions in the database and XMLDB
Some things may be acceptable to ignore, but it pays to do a check, particularly after an upgrade to make sure the upgrade process worked correctly and in particular you aren’t missing any core or plugin database tables that are defined in XMLDB, as these will pop up as database errors in your application sooner or later (e.g. “Error reading from database”).
If you need to build any missing core tables, remember they are defined under Developer > XMLDB Editor. From here find lib/db (core database tables) and choose Load, followed by Edit. Find the table you need and choose Edit. You can then use View SQL code to get the relevant SQL commands to create the table if it is missing from your database.
Also as a developer, make sure you are correctly utilising XMLDB for defining your plugin’s database tables. Taking shortcuts such as directly creating tables in the database without defining them in XMLDB will mean that they will pop up as unexpected when checking the database schema.
The following SQL will help you see which users are site admins in a MySQL (or MariaDB) database using the
find_in_set function to query the values listed in the mdl_config siteadmins key-value.
find_in_set(u.id, (select value from mdl_config where name = 'siteadmins'))
Note you need to use
find_in_set and NOT
in as it doesn’t handle the commas returned to separate each siteadmin’s user ID.