Thread: SSL connection

Hi,

I return on the SSL argument and I ask what are the main difficult in
developing this (important, I think) feature into the ODBC driver.
If I'm not wrong the odbc driver uses the libpq.dll functions to connect
to the database. Well, using that library should be easy to implement a
ssl connection using that appropriate parameter in the function used to
connect. The only problem at this point, I think, is only about openssl
(the pgsql docs says that to use ssl openssl is needed both by the
server and the client, I don't know exactly how libpq uses openssl to do
secure connections). Anyway there's a working version of openssl running
in the Cygwin environment so I don't think should be a real big problem
adding this feature to the odbc driver :-)

Comments?


Bye, Romaz

> -----Original Message-----
> From: Davide Romanini
>
> Hi,
>
> I return on the SSL argument and I ask what are the main difficult in
> developing this (important, I think) feature into the ODBC driver.
> If I'm not wrong the odbc driver uses the libpq.dll functions
> to connect
> to the database. Well, using that library should be easy to
> implement a
> ssl connection using that appropriate parameter in the
> function used to
> connect. The only problem at this point, I think, is only
> about openssl
> (the pgsql docs says that to use ssl openssl is needed both by the
> server and the client, I don't know exactly how libpq uses
> openssl to do
> secure connections). Anyway there's a working version of
> openssl running
> in the Cygwin environment so I don't think should be a real
> big problem
> adding this feature to the odbc driver :-)
>
> Comments?

Psqlodbc driver doesn't use libpq.dll.

regards,
Hiroshi Inoue

Friends,
    I've got a problem with my system, and I think it's an ODBC issue, tho it
could be from somewhere else.
    The problem is that when I try to look at a particular table using ODBC, it
returns garbage.  In Access it looks like the table has a bunch of duplicate
rows in it (I get 3809 records that are identical).  I think it might be an
ODBC issue because other types of connections (psql or Perl DBI) get the
data that I would expect.  I've done the following things to try to find out
where the problem lays, and haven't had any luck with any of them.
    I've:
    Dropped and reloaded the table.
    Loaded the table into another database.
    Set up a new ODBC data source to connect to the database.
    Set up a new access database to link the table to.
    Connected to the database using OpenOffice.org data source (the application
crashed).
    Opened the Access database on a different machine.

    While writing this it occurred to me to see if pgAdmin II could see the
data correctly, and it could, so maybe it is really an access problem.
    Can anyone point me toward a good way I can troubleshoot this further, or
let me know how they solved a similar problem?
Thanks,
Peter Darley