Re: Update on Access 97 and = NULL

"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
>> 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. 

This sounds like a plausible explanation.

> You are right. I'd like to fix it.
> When could we translate "= NULL" into "IS NULL" ?

Hmm ... before we go marching off in that direction, it would be a good
idea to verify that this is *really* what is supposed to happen.  Is
there any ODBC standard that we can consult to confirm that binding a
NULL parameter should cause that to happen?  My suspicion is that it's
just as much a spec violation if the ODBC driver does it as if the
backend does it.  Note that the KB article tells users they must fix
their queries, not that the ODBC layer will take care of it.

But, taking that assumption as correct for the moment ---

Given the choice of having the ODBC driver do this or letting the
backend do it, I'd have to say that I prefer leaving it in the backend,
because the ODBC driver just doesn't have enough understanding of SQL
syntax to be able to get it right.  It would take a major upgrade of the
driver's SQL parser before I'd have any confidence in the translation
being done correctly.

Yet ... in the long run that does need to happen, I think.  Some day
it'd be nice to see ODBC contain a full parser similar to ecpg's.
What I'm wondering about that is how we can reduce the maintenance load.
Michael Meskes spends a great deal of work trying to keep ecpg's grammar
in sync with the backend, and I fear it's a losing battle.  Is there
some way we could automatically generate backend/ecpg/ODBC parsers from
a common source?
        regards, tom lane