(string->number x 10) expects string but is getting #<sql-null>

[gknauth]

string->number: expects type <string> as 1st argument, given: #<sql-null>; other arguments were: 10

I get this error with the following:

(query-rows (string-append

"select a.type, "
"a.number, "
"a.due, "
"w.submitted, "
"w.raw_grade, "
"w.adj_grade, "
;"w.extension, "
"a.description "
"from work w "
"join assignment as a on w.fk_assignment=a.id "
"join term as te on te.code='F09' and a.fk_term=te.id "
"join student as s on s.handle='student123' "
"join course as co on co.code='CPTR 346' "
"join class as cl on cl.fk_course=co.id and cl.fk_term=te.id "
"join enrollee as e on w.fk_enrollee=e.id and e.fk_student=s.id and e.fk_class=cl.id "
"order by a.type, a.number"))

I can proceed without the error if I comment out the line:

"w.adj_grade, "

MySQL type of w.adj_grade is float.

I've traced the error to line 1911 of mysql.plt v1.5, inside text-decoder-map.

Apparently x is supposed to be a string, but sometimes it's #<sql-null>.

[jaz]

Ouch -- this one was blindingly obvious. It's actually the same bug that prompted the 1.4 release, but my fix for 1.4 was not a general solution. I use the field type information to convert the textual responses from MySQL into the appropriate scheme data, and I was only handling NULLs explicitly if the field type was NULL -- which it never would be... NULL values in CHAR/VARCHAR/TEXT columns worked beforehand, but that was just a happy coincidence. Now, I check for NULL values before applying the type-specific conversion function from the text-decoder-map.

(NULLs are encoded differently in prepared statements, so they weren't affected by this bug.)

Fixed in 1.6, freshly uploaded to PLaneT.

Thanks for the report, and please let me know if this doesn't fix your problem.

[jaz]

Somehow this ticket is appearing as 'open,' in PLaneT, even though it's closed here... Maybe this will work?