The data representation changes because that number, properly shown in an explicit fixed notation with enough decimal points, would show what you wanted. You saw 7.189543E-02 - which is actually 0.07189543 - instead of 7.2 (as a percent). At least two things are happening here.

First, because of that double-barrelled leading 0 (one to the left and one to the __immediate__ right of the decimal), Access by default switches to scientific notation. That is because 0.0xxx in common notation is an unnormalized fraction by Access (actually, VBA) standards. You might consider some kind of expression in your query to multiply the fractional number by 100.0 and then format it with a "00.0" or "##.#" template with an explicit % sign concatenated after it. I.e. use Format function & "%" to get your right result.

BUT the second thing that you have to watch out for is that you used a SINGLE for the representation and then went fractional with a decimal number that is not an integer power of two. Therefore, you invite some serious representational errors. The reason for this is that the fraction in Access SINGLE notation is a binary fraction with a limited number of bits, I think 23 bits total. A SINGLE is rated for 6 full decimal digits and part of a 7th digit in precision. But the fraction is actually 72/1000 if you look at it as a normalized fraction. That division by 1000 can be factored as THREE divisions by 10, which is really three divisions by 5 and three more divisions by 2. And there is the rub. Dividing by 5 is totally not good in binary because in binary fractions, 1/5 is an irrational number. I.e. you can divide 2 by 5 about as well as you can divide 10 by 3. It NEVER comes out even. And that is why I suggested you multiply by 100 to get rid of some of that irrationality. For what it is worth, switching to DOUBLE might or might not work to make it better. The binary fraction in 23 bits remains irrational when in 55 bits.