This kata's ROUND as well as DECIMAL keywords did not work on this problem for me. Whenever I tried to use them they didn't 'highlight' like normal keywords should, and then errors said 'no such functions exist'. Is there some setting I need to muddle with?

I fiddled around for at least thirty minutes trying to get it to work without them. Sure enough I clicked through to the solution and nope, everyone has used them just fine. ARGH.

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.

if you use certain fields in the select, then you still need to use them in ORDER BY.
Examples:
Right way:
SELECT a, b from ab ORDER BY b, a
Wrong way:
Select a, b from ab ORDER BY b

Spent over 15 minutes to figure it out, thank you.

Everything works correctly. If you have an issue, it's on your side only.

This kata's ROUND as well as DECIMAL keywords did not work on this problem for me. Whenever I tried to use them they didn't 'highlight' like normal keywords should, and then errors said 'no such functions exist'. Is there some setting I need to muddle with?

I fiddled around for at least thirty minutes trying to get it to work without them. Sure enough I clicked through to the solution and nope, everyone has used them just fine. ARGH.

The "games" collumun is the number of games that the player was in, not something like a game code. There is one row per player, not one row per game.

This comment is hidden because it contains spoiler information about the solution

If you select * from yankees, you'll note that there are only 11 players in the table, however, one of the tests is that the expected rows count 13

Looking at the tests, casting is apparently required

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

if you use certain fields in the select, then you still need to use them in ORDER BY.

Examples:

Right way:

SELECT a, b from ab ORDER BY b, a

Wrong way:

Select a, b from ab ORDER BY b

It's right, but it's not right enough. LOL Also, it is text.

This comment is hidden because it contains spoiler information about the solution

Might want to ensure at_bats = 100 in some test cases to catch out some incorrect answers

This comment is hidden because it contains spoiler information about the solution

Thank you MarishkaGoomy--anyone know how the FM output is different?

## Loading more items...