From: Warren Young Date: May 7 2011 10:24pm Subject: Re: SSQLS with BINARY column is sometimes not escaped List-Archive: http://lists.mysql.com/plusplus/9344 Message-Id: <6B0CE467-9F7C-4650-A4FC-99E656125DC5@etr-usa.com> MIME-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On May 7, 2011, at 4:08 PM, Kemet wrote: > * num_ is set to 51, which corresponds to "VARCHAR NULL". Indeed, I = mistakenly forgot to add the "NOT NULL" when creating the table. > * If escape_q is called, it returns FALSE. It sounds like a bug to me. > I corrected the table definition and now I get the same type 25 in = both cases. Good to know, and the correct thing in the end, but MySQL++ should = defend itself against being lied to like you did. :) > Question remains if there is a bug in escape_q (returning false for = all "nullable" types), or that this is caused because of a mismatch = between database definition (allowing NULL) and SSQLS definition (not = allowing NULL). I expect that the right thing is to do something like this: if (val.nullable && !val.is_null) { return val.value.escape_q(); // delegate to wrapped = type } else { // do what we do now } This is very vague pseudocode. It may have to be done with an overload = of escqpe_q() instead of an 'if' statement. You've been into that forest. Do you want to chop the bug tree down?=