Pavel Raiskup | 18 Nov 10:14 2014
Picon

making the testsuite installable

Hello all.

My issue with current testsuite solution:

  The testsuite requires 'root' account.  Thats needed because successful run
  requires PostgreSQL properly configured and running.  This is hardly
  achievable during package build because (e.g. in Fedora) we build packages
  under non-privileged user.

  Running git testsuite against distributed psqlodbc is not comfortable so
  I doubt users run the testsuite.  Running the testsuite automatically is
  not trivial.

It would be really nice to have the testsuite installed with 'make
install'.  That would allow us to package the testsuite as separated
(sub)package and distribute it to end-users (who should be able to have
enough privileges).  It would also allow me to write privileged scripts
for downstream testing.

Would you be interested in patches implementing this? .. 
* adding option ./configure --enable-dist-tests (default off)
* make tests sub-directory autoreconfed

Pavel

--

-- 
Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

(Continue reading)

蔡珂珂 | 15 Nov 07:47 2014

some questions in psqlodbc

Dear somebody:
    hello, I am eric from beijing. And I am a fresh man in psqlodbc. When I am studing at the psqlodbc source code, I have some questions. 
    In file named "odbcapi.c", the function named "SC_opencheck" are called almost everywhere, and in the function, why return some error when "the cursor is open"? And using git, I saw that change was beening done in 2004-01-06 17:58:22. Oh how old is it, but I can't understande why we can't use a cursor when it is opened or created by some other?
    And  in function "PGAPI_ExtendedFetch" in another file "results.c", which is called by SQLFetch, why seting cursor to start using function "SC_inc_rowset_start" or function "SC_set_rowset_start"?
Because we will maybe get rowdata next or not? 
    Could you understand me? My englist is poor, and I am afraid that I couldn't descript my questions clearly. I am sorry to apologize.

Best wishes!
                                                                                            Eric 
                                                                                            From Beijing 2014-11-15 


perry@processlinx.com | 14 Nov 16:47 2014

issue

We are running a third party application on windows. It inserts about 15,000 rows a day into a postgres database. From time to time we see an issue where the insert rollsbacks.

We do not have access to the client code but I would like to rule out odbc driver and postgres. We see no errors or warnings in the postgres log.

Windows 7 we have installed psqlodbc Driver Version 9.02.01.00 Unicode
Windows 7 client connects to a postgres sql server on freebsd 10.0 Postgresql 9.0.15

Looking for some gentle advice on how to diagnose this issue.

Thank You


mylog typical result
[1788-1055553.436]SC_init_Result(653b058)[1788-1055553.436]SC_Destructor: self=0653B058, self->result=00000000, self->hdbc=0483B460
[1788-1055553.436]reset_a_column_binding: entering ... self=0653B0E0, bindings_allocated=1, icol=1
[1788-1055553.436]APD_free_params:  ENTER, self=0653B158
...

mylog error result
[1788-1055559.077]SC_init_Result(653b058)[1788-1055559.077]SC_Destructor: self=0653B058, self->result=00000000, self->hdbc=0483B460
[1788-1055559.077][[SQLEndTran]][1788-1055559.077]entering PGAPI_Transact: hdbc=0483B460, henv=00000000
[1788-1055559.077]PGAPI_Transact: sending on conn 0483B460 '1'

psql log
[1055547.871]conn=0483B460, query='SELECT * , "ctid", "id" FROM raw_trans where ctid = '(7840,70)' '
[1055547.886]    [ fetched 1 rows ]
[1055547.902]conn=0483B460, query='COMMIT'
[1055553.374]conn=0483B460, query='insert into "public"."raw_trans" ("_name", "_numericid", "_value", "_timestamp", "_quality") values (E'OMRONS.LINE34.PULLER SPEED', 10, E'418', '2014-11-04 04:14:50.301'::timestamp, 192) returning ctid'
[1055553.405]    [ fetched 1 rows ]
[1055553.405]conn=0483B460, query='SELECT * , "ctid", "id" FROM raw_trans where ctid = '(7840,72)' '
[1055553.420]    [ fetched 1 rows ]
[1055553.436]conn=0483B460, query='COMMIT'
[1055559.014]conn=0483B460, query='insert into "public"."raw_trans" ("_name", "_numericid", "_value", "_timestamp", "_quality") values (E'OMRONS.LINE34.PULLER SPEED', 10, E'405', '2014-11-04 04:14:55.942'::timestamp, 192) returning ctid'
[1055559.045]    [ fetched 1 rows ]
[1055559.045]conn=0483B460, query='SELECT * , "ctid", "id" FROM raw_trans where ctid = '(7840,74)' '
[1055559.061]    [ fetched 1 rows ]
[1055559.077]conn=0483B460, query='ROLLBACK'
[1055559.264]conn=0483B460, query='close "SQL_CUR0653A4F0"'
[1055559.264]conn=0483B460, PGAPI_Disconnect
[1055559.295]conn=0483B460, PGAPI_DriverConnect( in)='DSN=PostgreSQL35W;UID=royal_plant1;PWD=processlinx;', fDriverCompletion=0
[1055559.295]DSN info: DSN='PostgreSQL35W',server='172.19.37.8',port='5432',dbase='royal',user='royal_plant1',passwd='xxxxx'
[1055559.295]          onlyread='0',protocol='7.4',showoid='0',fakeoidindex='0',showsystable='0'
[1055559.295]          conn_settings='', conn_encoding='(null)'
[1055559.295]          translation_dll='',translation_option=''
[1055559.295]Driver Version='09.02.0100,201306020000' linking 1600 static Multithread library
[1055559.295]Global Options: fetch=100, socket=4096, unknown_sizes=0, max_varchar_size=255, max_longvarchar_size=8190
[1055559.295]                disable_optimizer=0, ksqo=0, unique_index=1, use_declarefetch=1
[1055559.295]                text_as_longvarchar=1, unknowns_as_longvarchar=0, bools_as_char=1 NAMEDATALEN=64
[1055559.295]                extra_systable_prefixes='dd_;', conn_settings='' conn_encoding=''
[1055559.311]    [ PostgreSQL version string = '9.0.15' ]
[1055559.311]    [ PostgreSQL version number = '9.0' ]

Nicolas Beuzeboc | 12 Nov 23:20 2014

ODBC connection with SSL require stopped working after windows update KB2992611

ODBC connection with SSL require stopped working after windows update KB2992611 (https://technet.microsoft.com/en-us/library/security/ms14-066.aspx)

Rolling back this update solves that issue but I’d like to apply this critical windows security update.

 

Is there anything I can do to make it work with the update ?

 

Database log:

> LOG:  SSL error: wrong version number

> LOG:  could not receive data from client: Connection reset by peer

 

Using windows 7 pro 64 bit with postgresql odbc driver at https://ftp.postgresql.org/pub/odbc/versions/msi/psqlodbc_09_01_0200-x64.zip

 

Connecting to a postgresql server version :

# select version();

                                                  version

------------------------------------------------------------------------------------------------------------

PostgreSQL 9.1.4 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit

(1 row)

 

$ openssl version

OpenSSL 1.0.1 14 Mar 2012

Nicolas Beuzeboc
Database Analyst
Norchem
Ph: 928-526-1011 Ext: 242
Cell: 602-456-2183
nicolasb <at> norchemlab.com
norchemlab.com

Accredited by the College of American Pathologists (CAP-FDT)

This e-mail and any attachments may contain CONFIDENTIAL information protected by state and/or federal law, PROTECTED HEALTH INFORMATION. If you are not the intended recipient, any use or disclosure of this information is strictly prohibited; you are requested to delete this e-mail and any attachments, notify the sender immediately, and notify the Sterling Corporate Compliance Officer, Betsy Donat, at 1-877-648-5279 .

luis.gustavo | 12 Nov 17:39 2014
Picon

application_name

Hi,

I'm a developer in Brazil, and I need your help about how utilize a string connection with the application_name!! Is possible??

Thank You for attention,

Luis Gustavo
Email sent using ProApps
Christoph Berg | 12 Nov 13:21 2014
Picon

09.03.0400 broken on 32bit

Hi,

09.03.0400 is broken on all 32bit architectures:

https://buildd.debian.org/status/logs.php?pkg=psqlodbc&ver=1%3A09.03.0400-1

============== creating database "contrib_regression" ==============
CREATE DATABASE
ALTER DATABASE
============== running regression test queries        ==============
test sampletables             ... ok
test connect                  ... ok
test stmthandles              ... ok
test select                   ... ok
test commands                 ... ok
test multistmt                ... ok
test getresult                ... ok
test result-conversions       ... FAILED
test prepare                  ... ok
test params                   ... ok
test notice                   ... ok
test arraybinding             ... ok
test insertreturning          ... ok
test dataatexecution          ... ok
test boolsaschar              ... ok
test cvtnulldate              ... ok
test alter                    ... ok
test quotes                   ... ok
test cursors                  ... ok
test cursor-commit            ... ok
test positioned-update        ... ok
test catalogfunctions         ... ok
test bindcol                  ... ok
test lfconversion             ... ok
test cte                      ... ok
test deprecated               ... ok
test error-rollback           ... ok
test diagnostic               ... ok
test numeric                  ... ok
test odbc-escapes             ... ok

=======================
 1 of 30 tests failed. 
=======================

The differences that caused some tests to fail can be viewed in the
file "/home/cbe/projects/postgresql/psqlodbc/psqlodbc/test/regression.diffs".  A copy of the test
summary that you see
above is saved in the file "/home/cbe/projects/postgresql/psqlodbc/psqlodbc/test/regression.out".

/usr/lib/postgresql/9.4/lib/pgxs/src/makefiles/pgxs.mk:297: recipe for target 'installcheck' failed
make[1]: *** [installcheck] Error 1
make[1]: Leaving directory '/home/cbe/projects/postgresql/psqlodbc/psqlodbc/test'
regression.diffs:
***
/home/cbe/projects/postgresql/psqlodbc/psqlodbc/test/expected/result-conversions.out	2014-10-26
07:08:38.000000000 +0100
---
/home/cbe/projects/postgresql/psqlodbc/psqlodbc/test/results/result-conversions.out	2014-11-12
13:18:49.990297759 +0100
***************
*** 356,371 ****
  'textdata' (text) as SQL_C_INTERVAL_MINUTE_TO_SECOND: interval sign: 0 unknown interval type: 0
  '3234567901' (oid) as SQL_C_CHAR: 3234567901
  '3234567901' (oid) as SQL_C_WCHAR: 3234567901
! '3234567901' (oid) as SQL_C_SSHORT: -26915
! '3234567901' (oid) as SQL_C_USHORT: 38621
! '3234567901' (oid) as SQL_C_SLONG: -1060399395
  '3234567901' (oid) as SQL_C_ULONG: 3234567901
  '3234567901' (oid) as SQL_C_FLOAT: 3234567936.000000
  '3234567901' (oid) as SQL_C_DOUBLE: 3234567901.000000
! '3234567901' (oid) as SQL_C_BIT: 221
! '3234567901' (oid) as SQL_C_STINYINT: -35
! '3234567901' (oid) as SQL_C_UTINYINT: 221
! '3234567901' (oid) as SQL_C_SBIGINT: 3234567901
  '3234567901' (oid) as SQL_C_UBIGINT: 3234567901
  '3234567901' (oid) as SQL_C_BINARY: SQLGetData failed
  07006=Received an unsupported type from Postgres.
--- 356,371 ----
  'textdata' (text) as SQL_C_INTERVAL_MINUTE_TO_SECOND: interval sign: 0 unknown interval type: 0
  '3234567901' (oid) as SQL_C_CHAR: 3234567901
  '3234567901' (oid) as SQL_C_WCHAR: 3234567901
! '3234567901' (oid) as SQL_C_SSHORT: -1
! '3234567901' (oid) as SQL_C_USHORT: 65535
! '3234567901' (oid) as SQL_C_SLONG: 2147483647
  '3234567901' (oid) as SQL_C_ULONG: 3234567901
  '3234567901' (oid) as SQL_C_FLOAT: 3234567936.000000
  '3234567901' (oid) as SQL_C_DOUBLE: 3234567901.000000
! '3234567901' (oid) as SQL_C_BIT: 255
! '3234567901' (oid) as SQL_C_STINYINT: -1
! '3234567901' (oid) as SQL_C_UTINYINT: 255
! '3234567901' (oid) as SQL_C_SBIGINT: -1060399395
  '3234567901' (oid) as SQL_C_UBIGINT: 3234567901
  '3234567901' (oid) as SQL_C_BINARY: SQLGetData failed
  07006=Received an unsupported type from Postgres.

======================================================================

/home/cbe/tmp/pg_virtualenv.PhAgYW/log/postgresql-9.4-regress.log:
2014-11-12 13:18:43 CET [5632-1] LOG:  konnte IPv4-Socket nicht binden: Die Adresse wird bereits verwendet
2014-11-12 13:18:43 CET [5632-2] TIPP:  Läuft bereits ein anderer Postmaster auf Port 5433? Wenn nicht,
warten Sie einige Sekunden und versuchen Sie erneut.
2014-11-12 13:18:43 CET [5633-1] LOG:  Datenbanksystem wurde am 2014-11-12 13:18:42 CET heruntergefahren
2014-11-12 13:18:43 CET [5632-3] LOG:  Datenbanksystem ist bereit, um Verbindungen anzunehmen
2014-11-12 13:18:43 CET [5637-1] LOG:  Autovacuum-Launcher startet
2014-11-12 13:18:43 CET [5639-1] [unbekannt] <at> [unbekannt] LOG:  unvollständiges Startpaket
2014-11-12 13:18:52 CET [6108-1] cbe <at> contrib_regression ERROR:  relation "table_not_here" does not
exist at character 13
2014-11-12 13:18:52 CET [6108-2] cbe <at> contrib_regression STATEMENT:  INSERT INTO table_not_here
VALUES (1)
2014-11-12 13:18:52 CET [6117-1] cbe <at> contrib_regression ERROR:  invalid input syntax for integer:
"foo" at character 30
2014-11-12 13:18:52 CET [6117-2] cbe <at> contrib_regression STATEMENT:  INSERT INTO errortab VALUES ('foo')
2014-11-12 13:18:52 CET [6118-1] cbe <at> contrib_regression ERROR:  invalid input syntax for integer:
"foo" at character 30
2014-11-12 13:18:52 CET [6118-2] cbe <at> contrib_regression STATEMENT:  INSERT INTO errortab VALUES ('foo')
2014-11-12 13:18:52 CET [6119-1] cbe <at> contrib_regression ERROR:  invalid input syntax for integer:
"foo" at character 30
2014-11-12 13:18:52 CET [6119-2] cbe <at> contrib_regression STATEMENT:  INSERT INTO errortab VALUES ('foo')
2014-11-12 13:18:52 CET [6127-1] cbe <at> contrib_regression ERROR:  syntax error at or near "broken" at
character 1
2014-11-12 13:18:52 CET [6127-2] cbe <at> contrib_regression STATEMENT:  broken query 
2014-11-12 13:18:52 CET [6127-3] cbe <at> contrib_regression FATAL:  terminating connection due to
administrator command
2014-11-12 13:18:52 CET [6127-4] cbe <at> contrib_regression STATEMENT:  select
pg_terminate_backend(pg_backend_pid());select 1;select 1 
Stopping cluster 9.4/regress...

Mit freundlichen Grüßen,
Christoph Berg
-- 
Senior Berater, Tel.: +49 (0)21 61 / 46 43-187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Hohenzollernstr. 133, 41061 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE

--

-- 
Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Nils Gösche | 11 Nov 18:08 2014
Picon

Bug? {? = CALL insert_page_segment (?, ?)}

Hi!

I have a problem with newer versions of the ODBC driver. I made a small
testing example to reproduce the problem:

The following code works fine with version 09.02.0100 of the driver. With
09.03.0210, it crashes. With 09.03.0400, I get a strange exception and error
message.

This is all on Windows, 32-Bit. I tried Windows 7 and Windows 8.1; I also
tried Postgres versions 9.2.4, 9.2.9, 9.3.4 and 9.3.5, all 32-Bit.

Here is the create script for the database:

CREATE TABLE page_segments (
	task_id uuid,
	id uuid,
	PRIMARY KEY (task_id, id)
);

CREATE FUNCTION insert_page_segment(theTaskId uuid, theId uuid) RETURNS int
AS $$
DECLARE
	ret int NOT NULL := 0; 
BEGIN
	BEGIN
		INSERT INTO page_segments (task_id, id) VALUES (theTaskId,
theId); 
		ret := 1; 
	EXCEPTION WHEN unique_violation THEN
		-- ignore
	END; 
	RETURN ret; 
END
$$ LANGUAGE plpgsql;

And here is some C# code that calls the insert_page_segment function:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Data;
using System.Data.Odbc;

namespace ODBCTest
{
    class Program
    {
        const string ConnString =  <at> "Driver={PostgreSQL
Unicode};server=localhost;port=5432;database=stringtest;uid=cartan;pwd=...";
        static void Main(string[] args)
        {
            using (var conn = new OdbcConnection(ConnString))
            {
                conn.Open();
                Guid g1 = Guid.NewGuid();
                Guid g2 = Guid.NewGuid();
                Console.WriteLine("First call returns {0}",
CallTheFunc(conn, g1, g2));
            }
            Console.WriteLine("Press any key to exit...");
            Console.ReadKey(true);
        }

        static int CallTheFunc(OdbcConnection conn, Guid taskId, Guid id)
        {
            using (var trans = conn.BeginTransaction())
            {
                try
                {
                    const string insertCmdText =  <at> "{? = CALL
insert_page_segment (?, ?)}";
                    using (var insertCmd = new OdbcCommand(insertCmdText,
conn, trans))
                    {
                        var retParam = new OdbcParameter();
                        retParam.OdbcType = OdbcType.Int;
                        retParam.Direction = ParameterDirection.ReturnValue;
                        insertCmd.Parameters.Add(retParam);

                        var taskIdParam = new OdbcParameter();
                        taskIdParam.OdbcType = OdbcType.UniqueIdentifier;
                        taskIdParam.Value = taskId;
                        insertCmd.Parameters.Add(taskIdParam);

                        var idParam = new OdbcParameter();
                        idParam.OdbcType = OdbcType.UniqueIdentifier;
                        idParam.Value = id;
                        insertCmd.Parameters.Add(idParam);

                        insertCmd.ExecuteNonQuery();
                        int ret = (int) retParam.Value;

                        trans.Commit();
                        return ret;
                    }
                }
                catch
                {
                    trans.Rollback();
                    throw;
                }
            }
        }
    }
}

With the old 9.2.1 driver, the function just returns 1 as expected. With
9.3.4, I get an unusual InvalidOperationException in ExecuteNonQuery(),
saying

  "This OdbcTransaction has completed; it is no longer usable."

In the Postgres log file, I find this message:

2014-11-11 17:26:04 CET ERROR:  function insert_page_segment(unknown) does
not exist at character 8
2014-11-11 17:26:04 CET HINT:  No function matches the given name and
argument types. You might need to add explicit type casts.
2014-11-11 17:26:04 CET STATEMENT:  SELECT insert_page_segment ($1, $2)
2014-11-11 17:26:04 CET FATAL:  invalid frontend message type 0

Can anybody help me with this?

Regards,
--
Nils Gösche 
Don’t ask for whom the <Ctrl-G> tolls. 

--

-- 
Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

MURALIDHAR REDDY PESARU | 10 Nov 21:11 2014

ODBC Driver for Windows 64Bit

​Hi,


I am looking for PostgreSQL 9.3.5 ODBC driver for Informatica 9.6.1 but unable to find out the same.


We have installed the postgreSQL 9.3.5 server and unable establish the connectivity between informatica and DB server.


Could you please help me by providing the respective download link for windows 64bit.


Appreciate your hel on time.


Regards,

Murali



This e-mail communication and any attachments to it are confidential and privileged to Hexaware and are strictly intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message, you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited and may be unlawful.

Please notify the sender immediately and destroy all copies of this message along with all attachments thereto.
Ed Hutchinson | 11 Nov 01:25 2014
Picon

Connection string parameter "sslrootcert" does not work

Hi,
    I am using the psqlODBC driver to connect to Amazon RDS. I am able to connect successfully after enabling SSL encryption via the connection string parameter "sslmode=require". I want to now enable verification of server identity too, which means that I need to provide the CA certificate path to the Postgres driver. I tried the connection parameters "sslmode=verify-full;sslrootcert=<path to CA file>", but the driver is not able to pick up the file from the specified path (I tried on Windows and Mac OS X). Things work, however, when the certificate is placed in the default place the driver looks in - %APPDATA%\Roaming\postgresql\root.crt on Windows; ~/.postgresql/root.crt on Mac.

    Is this a bug that needs to be fixed or am I doing something wrong? I am using psqlodbc version 09_03_0300-1.

Thanks,
Ed

The resources I consulted:
Malcolm MacLeod | 4 Nov 19:37 2014

Re: Does psqlODBC actually work on osx?


> We use psqlODBC daily on OS X, on a mix of Mountain Lion and Mavericks
> machines for a fair amount of development activity, and have for a
> couple of years now. I maintain (somewhat haphazardly) the MacPorts
> port for psqlODBC. Which reminds me I should probably push the latest
> version. ;)
> 
> So, yes, it most definitely works on OS X.
Thanks, have you used the one in the "enterprise db" installer at all or
only the MacPorts one?
Can you confirm if it works with iodbctestw? Do you use an "ODBC
adminstrator" e.g. "Openlink ODBC Administrator" or only config files?

- Malcolm MacLeod

> 
> On Tue, Nov 4, 2014 at 10:15 AM, Malcolm MacLeod
> <malcolm.macleod <at> tshwanedje.com> wrote:
>         > >>> We have a client trying to connect to PostgreSQL server
>         9.2 from an osx
>         > >>> client with our software via ODBC, he has asked for
>         instructions to
>         > >>> assist him setting up.
>         > >>>
>         > >>> I have attempted the setup myself using psqlODBC and no
>         matter what I do
>         > >>> configuration wise, the driver fails to connect (via
>         iodbctestw and
>         > >>> iodbc administrator) stating that the password is
>         incorrect - I know
>         > >>> this is not the case because I am using identical
>         configuration to my
>         > >>> linux machine where it works fine.
>         > >> What is the exact error message you are getting?
>         > >> Are you connecting from within the same network as your
>         Linux machine?
>         > >> Just trying to eliminate the possibility that it is a
>         pg_hba.conf issue.
>         > > All on same internal network.
>         > > Server 10.0.0.3, working machine(s) 10.0.0.24, 10.0.0.25
>         etc. broken
>         > > machine 10.0.0.26
>         > > I've tried also setting the pg_hba.conf to 'trust' and
>         even then it
>         > > doesn't seem to work.
>         > >
>         > > Various config info and traces below.
>         > >
>         > >
>         > >
>         > > Snippet from configuration (Although I've played with
>         various other
>         > > options SSLmode etc. here as well)
>         > >
>         > > [test]
>         > > Driver=psqlODBC
>         > > Server=10.0.0.3
>         > > Database=todo
>         > > Username=postgres
>         > > Password=postgres13
>         > >
>         > >
>         > >
>         > >
>         > > iodbctestw error messsage:
>         > > 1: SQLDriverConnectW = FATAL: password authentication
>         failed for user
>         > > "postgres" (210) SQLSTATE=28P01
>         > Well it is not liking that password.
>         
>         I can connect using the exact same password from the exact
>         same machine
>         using pgadmin directly, as well as from multiple (non osx)
>         machines
>         using it also.
>         Occams razor tells me that it is far more likely that
>         psqlodbcw.so has
>         some or other issue than that the password somehow has
>         something wrong
>         with it or that I am suddenly incapable of doing basic
>         configurations
>         correctly. I would love to be wrong and find out that it is a
>         configuration issue as that would solve a lot of headaches but
>         I just
>         don't see where or how it could be possible.
>         
>         > Are you sure you do not have conflicting configurations?
>         Yes, this is a fresh snow leopard install on which I have
>         install postgres, iodbc administrator and nothing else.
>         Also changing various settings e.g. SSL in the config file
>         change the
>         behavior of iodbctest thus indicating that this is where it is
>         looking.
>         
>         > What file is the configuration you show above coming from?
>         /Library/ODBC/odbc.ini
>         - Which is the only odbc.ini file in existence on the machine,
>         all other
>         odbc.ini and .odbc.ini have been deleted, and I have only put
>         configuration into this one file.
>         
>         > What is in your odbc.ini file?
>         Exactly what I posted above plus the below for tracing:
>         [ODBC]
>         Trace=1
>         TraceFile=/Users/test/odbc.log
>         
>         
>         
>         > How are you running the test configuration?
>         iodbctestw "DSN=test;UID=postgres;PWD=postgres13" and various
>         similar
>         incantations e.g. with the user and password left out...
>         Also the test button in iODBC administrator
>         
>         
>         > Looking into the postmaster log to see what it logged about
>         this might
>         > prove informative.  It's not unusual for the log to contain
>         info
>         > that's
>         > intentionally not reported to the client.
>         2014-11-04 18:26:07 CAT FATAL   password authentication failed
>         for user
>         "postgres"
>         2014-11-04 18:26:07 CAT DETAIL  Connection matched pg_hba.conf
>         line 81:
>         "host    all             all             10.0.0.0/24
>            md5"
>         
>         Thats all of interest that postmaster has to say.
>         i.e. the password is wrong, except of course this is obviously
>         not the
>         case. I doubt the server is lying about this, so I'm pretty
>         sure that
>         the blame lies with psqlODBC (or with libiodbc and/or the
>         interface
>         between the two).
>         Could it be incorrectly passing the UTF32 (or is it 16?)
>         password to a
>         UTF8 system/iodbc call or similar thereby corrupting the
>         password?
>         I find it hard to believe that something this fundamental
>         could be
>         wrong/broken but I don't know what else to think - which is
>         why I ask if
>         anyone can verify having actually ever used psqlODBCw on osx
>         recently
>         without issue...
>         
>         Thanks,
>         Malcolm MacLeod
>         
>         
>         
>         --
>         Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
>         To make changes to your subscription:
>         http://www.postgresql.org/mailpref/pgsql-odbc
>         
> 
> 

--

-- 
Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Malcolm MacLeod | 4 Nov 16:54 2014

Does psqlODBC actually work on osx?

Hello,

We have a client trying to connect to PostgreSQL server 9.2 from an osx
client with our software via ODBC, he has asked for instructions to
assist him setting up.

I have attempted the setup myself using psqlODBC and no matter what I do
configuration wise, the driver fails to connect (via iodbctestw and
iodbc administrator) stating that the password is incorrect - I know
this is not the case because I am using identical configuration to my
linux machine where it works fine.

Has anybody actually tested psqlODBC on OSX recently? Does it actually
work? Is there some known issue that causes this password thing, if so
what is the workaround?
(I'm trying on Snow Leopard myself but even information about a more
recent version would be great to know)

Thanks,
Malcolm MacLeod

--

-- 
Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc


Gmane