> -----Original Message-----
> From: Nick Gorham [mailto:nick@easysoft.com]
>
> Hiroshi Inoue wrote:
> > Alain Picard wrote:
> >
> >>>>>>>Hiroshi Inoue writes:
> >>
> >>Hiroshi> I checked unixODBC sources a little. ISTM unixODBC checks
> >>Hiroshi> the existence of the function SQLColAttributes and if it
> >>Hiroshi> exists, it calls SQLColAttributes( not SQLColAttribute)
> >>Hiroshi> passing through the Field Identifier parameter.
> >>Hiroshi> Is it right ?
> >>
> >>I _think_ that's right, but I'll leave it to Nick or Peter
> to confirm.
>
> Ok, this is my take.
>
> SQLColAttributes is a ODBC 2 call, its depreciated in ODBC 3, so if a
> app calls SQLColAttributes, the DM will call SQLColAttributes in the
> driver (if it exists), otherwise it will call SQLColAttribute.
>
> If the app calls SQLColAttribute and the driver supports
> SQLColAttribute
> then its passed into the driver. If the driver only has
> SQLColAttributes
> then the DM will map some ODBC 3 values to their ODBC 2
> version (if they
> differ).
>
> Its made a bit stranger in that the value that SQLGetFunctions returns
> is the SAME for the two calls, so the only way the DM can
> tell which the
> driver has if by the functions exported by the shared lib.
>
> Does that help ?
Thanks. I already committed a change to remove ODBC2.x functions
for the ODBC 3 driver. According to Alain, it solved the
SQLColAttribte(s)
problem at least. However, there exists a BIGINT handling problem.
What I provided is bigint handling under Windows only. Unfortunately
I'm not good at portability issue under *nix.
regards,
Hiroshi Inoue