For security reasons if you DROP a stored procedure in MySQL any grants to use it are also removed. This makes perfect sense as stored procedures can be set to run internally as a different user that the one that called it. If the GRANT wasn’t removed it would be possible to have a perfectly innocent procedure removed and, a while later a new one added that happened to have the same name (I know that this would require a deal of disorganisation but hey) that could drop the whole DB. The user who had access to the first procedure would then have access to the new one (bad times).

While it makes sense that the GRANT is removed when the stored procedure is removed it doesn’t really make sense that you can’t update stored procedures, you have to drop and recreate them, thereby losing all the grants applicable to them every time – damn annoying

The solution . . .The solution is to make sure you get all of the applicable grants ready to put back into the database before you drop the stored procedure. However, unless you’re very organised (I’m not) or you have a limited number of DB users to manually check (we don’t) this can be a bit of a pain.

MySQL stores all the information about a users GRANTs and PRIVILEGEs in a database called mysql so rather than doing all those lookups manually and possibly missing something, why not just get the server to tell you who it thinks has access to what. To find all of the users (user/host pairs obviously) that have access to execute a procedure called procedureName in the database dbName you can use this query.

select User, Host FROM mysql.procs_priv WHERE Routine_name=’procedureName’ AND Db=’dbName’;

Which is great, but it does mean that you’re still going to have to rewrite all the queries to put those grants back in . . . why not use CONCAT to have the query output the finished queries for you??

select CONCAT(‘GRANT ‘, Proc_priv, ‘ ON PROCEDURE `’, Db, ‘`.`’, Routine_name, ‘` TO `’, User, ‘`@`’, Host, ‘`;’) FROM mysql.procs_priv WHERE Routine_name=’procedureName’ AND Db=’dbName’;

Bingo . . . just run this before you are going to DROP a stored procedure and you can add it’s output onto the end of the stored procedure script.  That way it’ll add the relevant grants straight back in

However if you’re a database without a function to find out age it’s a tad more tricky.

This just came up as someone in the office was writing a report that included calculating the users ages . . . the solution they used was good enough for our purposes but was also one of those little things that bugs you because you know there’s a better way to do it.

The initial solution was as follows . . . btw, let’s also chuck the date of birth into a variable to simplify the queries

SET @dateOfBirth=’1972-10-03′;

SELECT (DATEDIFF(NOW(), @dateOfBirth))/365;

As I said it’ll work but obviously there are going to be cases when it’s not quite right. The problem is obviously caused by the number of days in a year being inconsistent. Now MySQL has plenty of date functions built into it that we can leverage here so let’s see what we can come up with.

In order to get some more precision I first thought to convert the period from DOB to now into seconds . . .

SELECT datediff(NOW(), @dateOfBirth)*24*60*60;

We can then convert that back to a date since epoch using,

SELECT from_unixtime((datediff(NOW(), @dateOfBirth))*24*60*60);

then we rip the year out of that newly created date and take 1970 away from it to get the final age . . .

SELECT date_format(from_unixtime((datediff(NOW(), @dateOfBirth))*24*60*60), ‘%Y’)-1970;

BINGO . . . err, oopsie . . . that ain’t gonna work for anyone born before the epoch is it (because the from_unixtime function will return NULL for any negative values passed to it).  As usual I’ve gone off in the first direction I’d thought of and not bothered th check things out on the way.  Deep breath time and start again then . . .

Let’s start simple,

SELECT YEAR(CURRENT_DATE()) – YEAR(@dateOfBirth);

That’ll work fine as long as the month/day of the birthday has already been passed during the current year, if it hasn’t we need to take one away (eugh, sounds hacky again). To find if we’ve passed that date we can use,

SELECT date_format(CURRENT_DATE(), ‘%m-%y’)<date_format(@dateOfBirth, ‘%m-%y’);

and then putting it all together,

SELECT YEAR(CURRENT_DATE()) – YEAR(@dateOfBirth) – (date_format(CURRENT_DATE(), ‘%m-%y’)<date_format(@dateOfBirth, ‘%m-%y’)) AS age;

Well . . . it works but I know there must be a simpler way to do it – I’ll have another look later when I’m not in the office but at least this woodpecker has been put to bed for now!