Re: unixODBC, PostgreSQL 7.3 + ODBC V3 drivers?
От | Hiroshi Inoue |
---|---|
Тема | Re: unixODBC, PostgreSQL 7.3 + ODBC V3 drivers? |
Дата | |
Msg-id | 003101c2cd11$ce99cfc0$0e283ddb@PbgX обсуждение исходный текст |
Ответ на | unixODBC, PostgreSQL 7.3 + ODBC V3 drivers? (Alain Picard <Alain.Picard@memetrics.com>) |
Список | pgsql-odbc |
> -----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
В списке pgsql-odbc по дате отправления: