I've been working on more efficient and faster MySQL queries. I have one where I need to sum up a column from a bunch of rows. The column is calculated and rounded based on user rounding preferences, so the method for rounding uses a parameter.

I found that using a parameter generates a quoted factor, and that causes the round function to act like a FLOOR instead of a CEILING.

You can easily see it in this example:

```
mysql> SELECT ROUND(1.945,2), ROUND((ROUND((7002) / '1') * '1') / 3600,2) AS param_rounded, ROUND((ROUND((7002) / 1) * 1) / 3600,2) AS hard_rounded;
+----------------+---------------+--------------+
| ROUND(1.945,2) | param_rounded | hard_rounded |
+----------------+---------------+--------------+
|           1.95 |          1.94 |         1.95 |
+----------------+---------------+--------------+

```

The `7002` value is a real-work example from my data (it's actually a calculated value as well), and `7200/3600 == 1.945`. You can see that `param_rounded`, using `'1'` (quoted) factors results in incorrect rounding. That's what was happening to me since I always use parameterized queries. `hard_rounded` is what I'm now doing, first confirming that the factors are appropriate values (they come from a database integer field anyway, so I'm not worried about injection from them) and inserting them directly into the SQL string.

**EDIT**
Using the appropriate data type in a parameter does result in correct rounding. I located the incorrect parameter type in the library I was using for queries.

However, I don't think it should matter, given that the actual number provided the final round in MySQL is correct -- 1.945. The division and multiplication factors occur before that final round, so what I'm giving MySQL works out to `ROUND(1.945)`, which it returns incorrectly. If you output the factors without the final round, you get a column result of 1.945.