> -----Original Message-----
> From: Mike Mascari [mailto:mascarm@mascari.com]
>
> Tom Lane wrote:
> >
> > Mike Mascari <mascarm@mascari.com> writes:
> > > However, I did find this
> > > explanation as to why on the Microsoft Knowledge Base:
> >
> > > http://support.microsoft.com/support/kb/articles/Q237/9/92.ASP
> >
> > Interesting. Apparently, at this point our "Microsoft-compatible"
> > hack is arguably *failing* to be Microsoft-compatible.
> >
> > The KB article is carefully written to make it sound like the only
> > "foo = NULL" queries out there are mistakes made by users; but wasn't
> > the original issue that Access97 itself would generate a bogus query?
>
[snip]
>
> Another possibility, one that Hiroshi suggested and that can be seen in
> the ODBC log files, is that Access 97 is using prepared statements which
> eventually call the ODBC driver's SQLPrepare() function like this:
>
> SQLPrepare(hstmt, "UPDATE employees SET salary = ? WHERE employeeid =
> ?", SQL_NTS);
>
> and later, a call to:
>
> SQLBindParameter(hstmt, 1, SQL_PARAM_INPUT, SQL_C_FLOAT, SQL_REAL,
> 7, 0, &salary, 0, &salaryind);
> SQLBindParameter(hstmt, 2, SQL_PARAM_INPUT, SQL_C_ULONG, SQL_INTEGER,
> 10, 0,
> &employee, 0, &employeeind);
>
> If the last parameter is set to SQL_NULL_DATA, then that means that the
> last parameter is NULL. That means that the query must be rewritten by
> the driver to "IS NULL" instead of "= NULL". Unfortunately, it *appears*
> our ODBC driver doesn't do that.
You are right. I'd like to fix it.
When could we translate "= NULL" into "IS NULL" ?
SELECT statement OK ? SET xxxx = NULL NG , xxxx = NULL NG ? otherwise OK ?
.....
Comments ?
regards,
Hiroshi Inoue
