Re: 9.0 Driver

Is there a 9.0 Driver?

Thanks,
Jason Tesser
dotCMS Lead Development Manager
1-305-858-1422

Looks like they're working on a 9.0 version in the HEAD code tree at the
CVS repository.

http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/docs/

Maybe you could try building it?

http://psqlodbc.projects.postgresql.org/win32-compilation.html
http://psqlodbc.projects.postgresql.org/unix-compilation.html

Regards,

Scott Langley
slangley(at)scharp(dot)org

psqlODBC release notes
------------------------------------------------------------------------

psqlODBC 09.00.0100 Prep Release

Changes:
1.) Allow password which contains special characters like {,},=,;.
2.) Add a new data source option which makes it possible to use Kerberos
for Windows library to reply to GSSAPI authentication request.
3.) Native support for SSPI Kerberos or Negaotiate service. It may be
useful for the 64-bit drivers.
4.) Fix an oversight of Memory overflow handling.
5.) Removed "#define SQL_WCHART_CONVERT" which causes a trouble on some
platforms.
6.) Removed the use of misused strcat_s together with snprintf_s (bug
report from Jap-Peter Seifert) and use strlcat instead of strncat.
7.) Fix a bug about pre-execute behavior in case of protocol v2 or earlier.
8.) Use poll() instead of select() when it's available.
9.) Take comments or line comments in a query into account.
10.) Fix a crash bug on authentication failures.
11.) Take --without-iodbc(unixODBC) configure option into account.
12.) Apply the patch by Peter Crabtree which fixes a crash bug.
13.) Improve the handling of bools_as_char case.
14.) Fix a bug when creating a connection string.

Jason Tesser wrote:
> Is there a 9.0 Driver?
>
> Thanks,
> Jason Tesser
> dotCMS Lead Development Manager
> 1-305-858-1422

On Fri, 6 Aug 2010, Scott Langley wrote:

> Looks like they're working on a 9.0 version in the HEAD code tree at the CVS
> repository.
>
>     http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/docs/

That's the ODBC driver.

I aim to produce a 9.0 driver beta release to go with RC1 of the server.

Kris Jurka

Great thanx Kris that is what I was wondering.

Thanks,
Jason Tesser
dotCMS Lead Development Manager
1-305-858-1422

On Fri, Aug 6, 2010 at 4:49 PM, Kris Jurka <books(at)ejurka(dot)com> wrote:

> I aim to produce a 9.0 driver beta release to go with RC1 of the server.

There is, I believe, a problem with the JDBC driver in that it gives very poor performance doing a refreshRow. The problem is that the driver queries the server for every column in the resultset.

I implemented a quick and dirty fix by modifying the driver to (on demand) use the labels returned in the resultset.

This solution of course will fail if the original query used an alias for a column. Other than that, it seems to be a good solution.

Apparently I am the only one who uses refreshrow, because I reported the fact that it was slow in January (and there was a little discussion) but when in April I reported my crude solution there was no discussion.

John

On Sun, 8 Aug 2010, John T. Dow wrote:

> There is, I believe, a problem with the JDBC driver in that it gives
> very poor performance doing a refreshRow. The problem is that the driver
> queries the server for every column in the resultset.
>
> I implemented a quick and dirty fix by modifying the driver to (on
> demand) use the labels returned in the resultset.
>
> This solution of course will fail if the original query used an alias
> for a column. Other than that, it seems to be a good solution.
>
> Apparently I am the only one who uses refreshrow, because I reported the
> fact that it was slow in January (and there was a little discussion) but
> when in April I reported my crude solution there was no discussion.

I think it's a combination of factors, few people use refreshRow and fewer
people use it on results with hundreds of columns. Yes, it is slow, but
it isn't abysmal and it's only slow for the first refreshRow execution
on the ResultSet, so subsequent refreshes are fast. As you've stated, the
solution you've implemented is inadequate for the general case, so I'm not
sure what further discussion there should be about it. Is there something
in particular you'd like feedback on?

So yes, it's a known issue, but not a high priority one.

Kris Jurka