When you use only integers in a division, you will get integer division. When you use (at least one) double or float, you will get floating point division (and the answer you want to get).

So you can declare one or both of the variables as float/double
cast one or both of the variables to float/double.
Do not just cast the result of the integer division to double: the division was already performed as integer division, so the numbers behind the decimal are already lost.

from: https://stackoverflow.com/questions/1666407/sql-server-division-returns-zero

Not an issue.

Old question, but since there's no answer yet:

That's how arithmetic operations work in most programming languages, and sql. If you have an operation, e.g. "+" on two different types, the runtime tries to match the types, usually by casting the "lower precision" type value to the "higher precision" type. The result is then of the common higher precision type. If you transform (or better cast) one value to a data type with higher precision, the other operand will be casted automatically to match. (e.g. int + int = int, float + int = float, float + double = double) If such a conversion is not possible you get an error.

It seems to me that the generated data is seriously hampering this Kata. I actually passed the test by lowering the minimum required price to 9 times lower what it was required. And even then, I had to run the code about 5 times before it worked.

I would always get get everything correct, but then I would get this "undefined method `keys' for nil:NilClass
Simplified backtrace: block (3 levels) in " error, which as far as I read from comments, it's because one of the columns got no data back from the generated data table.

Is there a way not to hardcode this? Maybe a function like next_column or something similar?

Agreed. It only worked with one of the two, and that should be better specified.

Maybe I'm not that experience, but by trying to use the actual command mentioned in the Kata, I would've never completed it.

I noticed some solutions don't quite hit the "atbats" condition correctly. Maybe add some extra rows to "make or break" a solution based on that, actually selecting the wrong amount of rows if the condition isn't set up properly?

I wonder though, I transformed both values to be able to get the result I wanted. Though seeing some other codes, people only really converted one value. Why is that?

I got caught a bit off guard by the casting, since I've never used them on an PL/SQL query, but the exercise in itself was cool.

Somewhat complex looking Kata with simple solution. Very nice!