Re: ODBC Developers

> -----Original Message-----
> From: Peter Eisentraut [mailto:peter_e(at)gmx(dot)net]
> Sent: 16 July 2004 07:23
> To: Dave Page; pgsql-odbc(at)postgresql(dot)org
> Subject: Re: [ODBC] ODBC Developers
>
> Dave Page wrote:
> > 1) ODBC 3 compliance should be checked. Are all the required ODBC
> > functions present. Do they work as expected.
>
> A brief status on this: We have all ODBC 3 functions in the
> code, but the following functions claim various forms of "not (fully)
> implemented":
>
> BrowseConnect
> ColumnPrivileges
> DescribeParam
> GetDescRec
> SetDescRec
>
> Whether any function works as expected is of course undecidable. :-)

Hmm, OK.

> > 2) Ditto, Unicode versions of all the functions.
>
> We have almost all the required Unicode functions, but some
> functions are in the file odbcapi25w.c, which is not linked
> in anywhere. What's up with that?

All the functions in there are deprecated in ODBC3 (as well as the ansi
equivalents). The driver manager will re-map any calls to them to the
ODBC3 replacements:

SQLColAttributes(W) -> SQLColAttribute(W)
SQLError(W) -> SQLGetDiagRec(W)
SQLGetConnectOption(W) -> SQLGetConnectAttr(W)
SQLSetConnectOption(W) -> SQLSetConnectAttr(W)

> The function GetDescRecW is completely missing.

Yup, it's missing it's placeholder. The driver does correctly report
that it is not implemented so there is no real problem, just an
incomplete api. I'm guessing not many apps use it...

I have removed the comment that says that SQLGetDescRecW is in
odbcapi30w.c

Which makes me think - should we add or remove placeholders for
unimplemented functions? The important thing is that SQLGetFunctions is
correct of course, however we should be consistent. I'm kinda on the
fence about which way to go on that one. On one had the placeholders are
useful reminders that work needs to be done - on the other, they do add
to the code needlessly.

> The additional required SQL functions are also mostly
> present, but there seems to be some duplication/overlap
> between convert.c and odbc.sql, that isn't quite clear to me yet.

convert.c should (imho) make odbc.sql obsolete as much as possible.

> Overall it looks quite good from the conformance point of view.

:-) Thanks Peter.