Thread: psqlodbc-8.2.200

psqlodbc-8.2.200

From
Patrick Welche
Date:
I just tried the psqlodbc-08_02_0200 msi on Windows XP Pro SP2. After
setting up an odbc link (identical to a 08_01_0200 working one), and clicking
"test", I get

odbcad32.exe:
Error signature:
  AppName: odbcad32.exe  AppVer: 3.525.1117.0  ModName: psqlodbc30a.dll
  ModVer: 8.2.2.0  Offset: 00015a22

Nothing hits the postgresql server - all dead beforehand.. Thoughts? Debugging
psqlodbc.msi ?

Cheers,

Patrick

Re: psqlodbc-8.2.200

From
Stijn Vanroye
Date:
If you went from 08_01_0200 directly to 08_02_0200, did you first
uninstall the 8.1 branch before installing anything from the 8.2 branch?

It says to do so in the readme file bundled with 8.2.1 download. I guess
that's also true for the 8.2.2.

Regards,

Stijn.

Patrick Welche schreef:
> I just tried the psqlodbc-08_02_0200 msi on Windows XP Pro SP2. After
> setting up an odbc link (identical to a 08_01_0200 working one), and clicking
> "test", I get
>
> odbcad32.exe:
> Error signature:
>   AppName: odbcad32.exe  AppVer: 3.525.1117.0  ModName: psqlodbc30a.dll
>   ModVer: 8.2.2.0  Offset: 00015a22
>
> Nothing hits the postgresql server - all dead beforehand.. Thoughts? Debugging
> psqlodbc.msi ?
>
> Cheers,
>
> Patrick
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq
>

Re: psqlodbc-8.2.200

From
Patrick Welche
Date:
For some reason I didn't get Stijn's reply
http://archives.postgresql.org/pgsql-odbc/2006-11/msg00024.php
through the email, so for the sake of the archive, the problem
fixed itself. I think this is because the psqlodbc-08_02_0200.msi
was assigned to the client with active directory, and in the
meantime the client was rebooted several times, so whatever
went wrong with the assignment eventually righted itself.
Not very scientific is it..

Cheers,

Patrick

Re: psqlodbc-8.2.200

From
"Benjamin Krajmalnik"
Date:
Running latest release of PostgreSQL ODBC Driver (8.02.0200).

Does the ODBC driver for Windows use connection pooling?

I have a Windows application which is using the driver.
I have connection pooling enabled, and the application notifies the
driver to use connection pooling (per the developer).

I saw a huge disparity when running the queries (a stored procedure
call) via psql locally and via the odbc driver (in this case, I am
referring to the statement duration as logged by postgresql).  The call
being made is a "select * from sp_name(parameters)".
I have about an 8:1 performance degradation in the statement duration
when called via ODBC compared to directly in psql (as reported by the
postgres log file).

I have not tried running the query through pgAdmin to see what execution
speed I get.
However, when I turned connection loggin on, I noticed that every single
call to the stored procedure is creating a new connection (so it appears
it is not honoring the connection pooling, which I believe results in
quite a bit of overhead for each statement being called).

TIA,

Benjamin