// Let assume that
// lastRuntime=10
SET paramDelay = 555;
SET nextRunTime = lastRunTime + paramDelay;
// THEN nextRuntime = 10 + 555 ----> = 565
// LET ASSUME THAT THIS UPDATE IS EXECUTED CORRECTLY
// UPDATE `apc` SET `value` = nextRunTime WHERE `key` = paramKey;
SET paramDelay = nextRunTime - lastRunTime;
// paramDelay = 565 - 10 ----->>>> 555 ....
so I don't see any problem regarding to the result, however seems that your code is generating a SQLWARNING (didn't have time to test why)... test the procedure just commenting that EXIT HANDLER and see what happen... hope this help
I'll give that a shot - I think I already tried that but will try it again.
I had the "SET paramDelay = 555;" sprinkled all over the place with different numbers to try to get an idea of what was happening. It was being set to different values below those lines but the corresponding values were never returned. Without the "SET paramDelay = 555;" line in there, it comes back out unchanged.
I'll do some more digging and see if maybe it's getting changed back to 555 even with the other code in there and also check to make sure the default values of NULL aren't screwing anything up.
Without the "SET paramDelay = 555;" line in there, it comes back out unchanged.
for what I see that is absolutely correct with that code... take out completely the SET paramdelay=555 (or assign any value to it) and you always are going to get the same value back.
I did test your code commenting the SQLWARNING line and it does what it is supposed to do (with or without changing the paramdelay in the procedure)