Overview
Features
Download
Documentation
Community
Add-Ons & Services

Poco::Data::ODBC with PostgreSql assertion

Please post support and help requests here.

Poco::Data::ODBC with PostgreSql assertion

Postby phireis » 03 Oct 2007, 02:15

Using Poco::Data::Sqlite worked fine in all cases, but using Poco Data ODBC, with odbc-postgresql (http://odbc.postgresql.org/) on Debian 4.0.
I can create a session, retrieve a single "count(*)" from a table, and retrieve an int column from a table in a vector, retrieve a single value into a string,
I got some assertion:

I got this when trying to execute a sql with a use(int), into(vector), and some other cases:

Assertion violation: sizeof(_connectionName) > none.length() [in file "include/Poco/Data/ODBC/Diagnostics.h", line 181]

In one case, this message appeared after that assertion:

PocoTest: pthread_mutex_lock.c:82: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.

Have anyone used Poco Data with Postgresql and ODBC?


Thanks in advance,

Philipe


phireis
 
Posts: 12
Joined: 21 Oct 2006, 03:18

Re: Poco::Data::ODBC with PostgreSql assertion

Postby alex » 03 Oct 2007, 03:10

> Have anyone used Poco Data with Postgresql and ODBC?

Yes, with both psqlodbc and ngODBC. You can find the tested platforms/driver managers and DB versions in the ODBCPostgreSQLTest.h

Can you post following:

* POCO version
* ODBC driver
* ODBC driver manager version
* code sample

so we can go from there. I may not be able to provide any help before next week, though. Also, if you are not using it already, then I recommend to try subversion code which has a lot of fixes.

We'd also very much like to see native PostgreSQL connector, so if you have any interest in contributing, email me directly at(aleskx, dot(gmail, com))

Alex
alex
 
Posts: 1143
Joined: 11 Jul 2006, 16:27
Location: United_States

Re: Poco::Data::ODBC with PostgreSql assertion

Postby alex » 03 Oct 2007, 03:51

> I can create a session, retrieve a single "count(*)" from a table, and retrieve an int column from a table in a vector, retrieve a single value into a string,
> I got some assertion:

I think I know where your problem is- PostgreSQL returns 64-bit integer for count(*). See SQLExecutor.cpp, line 1980 in TestSuite

HTH

Alex
alex
 
Posts: 1143
Joined: 11 Jul 2006, 16:27
Location: United_States

Re: Poco::Data::ODBC with PostgreSql assertion

Postby phireis » 07 Oct 2007, 21:13

I forgot to mention I'm using Debian Etch.

>Can you post following:

> * POCO version
> * ODBC driver
> * ODBC driver manager version
> * code sample

Poco 1.3.1
odbc-postgresql 1:08.01.0200
unixODBC 2.2.11

My code was only simple tests:
*The count worked;
*Selecting into single int value worked;
*Any "use(anything)" resulted int the assertion;
*Selecting a column into a vector (int or string) resulted in assertion too.

I'll try on subversion code.
I don't think I'm skilled enough to help on a native connector.

Thanks for the great framework,

Philipe
phireis
 
Posts: 12
Joined: 21 Oct 2006, 03:18

Re: Re: Poco::Data::ODBC with PostgreSql assertion

Postby alex » 08 Oct 2007, 13:03

> My code was only simple tests:
> *Any "use(anything)" resulted int the assertion;

Any can not be used as parameter to use because framework does not know what the target column type is.

> *Selecting a column into a vector (int or string) resulted in assertion too.

It's hard to tell why without seeing the code. You may want to look into SQLExecutor::simpleAccessVector() for examples.
Extracting a type that is not compatible may be causing exception. Can you post code and the definition of your table?

> I'll try on subversion code.

It will not help with Any and I'm not sure whether it will help with the other problem you have, either.

> I don't think I'm skilled enough to help on a native connector.

ok, fair enough. It never hurts to ask so I always do ;-)

> Thanks for the great framework,

You're welcome. Please spread the word.

Alex
alex
 
Posts: 1143
Joined: 11 Jul 2006, 16:27
Location: United_States

Re: Poco::Data::ODBC with PostgreSql assertion

Postby phireis » 09 Oct 2007, 02:02

^poco-1.3.1-data/Data/ODBC/testsuite/bin/Linux/i686$ ./testrunnerd N7CppUnit10TestCallerI18ODBCPostgreSQLTestEE.testSimpleAccess
Oracle driver NOT found, tests will fail.
!!! WARNING: No driver or DSN found. Oracle tests will fail !!!
PostgreSQL driver NOT found, tests will fail.
*** Connected to postgres-test(myConnectionString)
DB2 driver NOT found, tests will fail.
!!! WARNING: No driver or DSN found. DB2 tests will fail !!!
MySQL driver NOT found, tests will fail.
!!! WARNING: No driver or DSN found. MySQL tests will fail !!!
SQLite3 driver NOT found, tests will fail.
!!! WARNING: No driver or DSN found. SQLite tests will fail !!!

testSimpleAccess:

Assertion violation: sizeof(_connectionName) > none.length() [in file "include/Poco/Data/ODBC/Diagnostics.h", line 181]

*** glibc detected *** ./testrunnerd: corrupted double-linked list: 0x081497b0 ***
======= Backtrace: =========
/lib/i686/cmov/libc.so.6[0xb7a60379]
/lib/i686/cmov/libc.so.6[0xb7a61aee]
/lib/i686/cmov/libc.so.6(cfree+0x90)[0xb7a65780]
/usr/lib/odbc/psqlodbca.so(SC_initialize_stmts+0x9a)[0xb798fcaa]
/usr/lib/odbc/psqlodbca.so(SC_Destructor+0x72)[0xb7991032]
/usr/lib/odbc/psqlodbca.so(PGAPI_FreeStmt+0xdd)[0xb799185d]
/usr/lib/odbc/psqlodbca.so(SQLFreeHandle+0x91)[0xb79991a1]
/usr/lib/libodbc.so.1[0xb7c7d7f6]
/usr/lib/libodbc.so.1(SQLFreeHandle+0x25)[0xb7c7deb5]
/mypath/poco-1.3.1-data/lib/Linux/i686/libPocoODBCd.so.4(_ZN4Poco4Data4ODBC6HandleIPvLs3EED1Ev+0x28)[0xb7fbb494]
/mypath/poco-1.3.1-data/lib/Linux/i686/libPocoODBCd.so.4(_ZN4Poco4Data4ODBC17ODBCStatementImplD0Ev+0x19f)[0xb7fb653f]
/mypath/poco-1.3.1-data/lib/Linux/i686/libPocoDatad.so.4(_ZN4Poco9SharedPtrINS_4Data13StatementImplEE7releaseEv+0x7d)[0xb7f45d91]
/mypath/poco-1.3.1-data/lib/Linux/i686/libPocoDatad.so.4(_ZN4Poco9SharedPtrINS_4Data13StatementImplEED1Ev+0x1d)[0xb7f45deb]
/mypath/poco-1.3.1-data/lib/Linux/i686/libPocoDatad.so.4(_ZN4Poco4Data9StatementD1Ev+0x20)[0xb7f45884]
./testrunnerd[0x808e125]
./testrunnerd[0x808f987]
./testrunnerd(_ZN18ODBCPostgreSQLTest16testSimpleAccessEv+0x111)[0x8095bc3]
./testrunnerd[0x8099bf8]
/mypath/poco-1.3.1-data/lib/Linux/i686/libCppUnitd.so.1(_ZN7CppUnit8TestCase3runEPNS_10TestResultE+0x50)[0xb7d0b36c]
/mypath/poco-1.3.1-data/lib/Linux/i686/libCppUnitd.so.1(_ZN7CppUnit10TestRunner3runEPNS_4TestE+0x37)[0xb7d0d227]
/mypath/poco-1.3.1-data/lib/Linux/i686/libCppUnitd.so.1(_ZN7CppUnit10TestRunner3runERKSt6vectorISsSaISsEE+0x26d)[0xb7d0d503]
./testrunnerd[0x8060cd4]
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7a0e050]
./testrunnerd(__gxx_personality_v0+0x205)[0x805f311]
======= Memory map: ========
08048000-08113000 r-xp 00000000 03:01 2002805 /mypath/poco-1.3.1-data/Data/ODBC/testsuite/bin/Linux/i686/testrunnerd
08113000-08115000 rw-p 000cb000 03:01 2002805 /mypath/poco-1.3.1-data/Data/ODBC/testsuite/bin/Linux/i686/testrunnerd
08115000-08204000 rw-p 08115000 00:00 0 [heap]
b7500000-b7521000 rw-p b7500000 00:00 0
b7521000-b7600000 ---p b7521000 00:00 0
b76aa000-b76b9000 r-xp 00000000 03:01 1937175 /lib/i686/cmov/libresolv-2.6.1.so
b76b9000-b76bb000 rw-p 0000f000 03:01 1937175 /lib/i686/cmov/libresolv-2.6.1.so
b76bb000-b76bd000 rw-p b76bb000 00:00 0
b76bd000-b76e1000 r-xp 00000000 03:01 745910 /usr/lib/libk5crypto.so.3.1
b76e1000-b76e2000 rw-p 00024000 03:01 745910 /usr/lib/libk5crypto.so.3.1
b76e2000-b76f6000 r-xp 00000000 03:01 739647 /usr/lib/libz.so.1.2.3.3
b76f6000-b76f7000 rw-p 00013000 03:01 739647 /usr/lib/libz.so.1.2.3.3
b76f7000-b76fc000 r-xp 00000000 03:01 1937142 /lib/i686/cmov/libcrypt-2.6.1.so
b76fc000-b76fe000 rw-p 00004000 03:01 1937142 /lib/i686/cmov/libcrypt-2.6.1.so
b76fe000-b7725000 rw-p b76fe000 00:00 0
b7725000-b77aa000 r-xp 00000000 03:01 745912 /usr/lib/libkrb5.so.3.3
b77aa000-b77ac000 rw-p 00085000 03:01 745912 /usr/lib/libkrb5.so.3.3
b77ac000-b78d5000 r-xp 00000000 03:01 756524 /usr/lib/i686/cmov/libcrypto.so.0.9.8
b78d5000-b78ea000 rw-p 00128000 03:01 756524 /usr/lib/i686/cmov/libcrypto.so.0.9.8
b78ea000-b78ed000 rw-p b78ea000 00:00 0
b78ed000-b7929000 r-xp 00000000 03:01 756525 /usr/lib/i686/cmov/libssl.so.0.9.8
b7929000-b792d000 rw-p 0003b000 03:01 756525 /usr/lib/i686/cmov/libssl.so.0.9.8
b792d000-b7948000 r-xp 00000000 03:01 743829 /usr/lib/libpq.so.5.0
b7948000-b7949000 rw-p 0001b000 03:01 743829 /usr/lib/libpq.so.5.0
b795d000-b79ab000 r-xp 00000000 03:01 2199754 /usr/lib/odbc/psqlodbca.so
b79ab000-b79ac000 rw-p 0004e000 03:01 2199754 /usr/lib/odbc/psqlodbca.so
b79ac000-b79ad000 rw-p b79ac000 00:00 0
b79ad000-b79b6000 r-xp 00000000 03:01 1937149 /libAbortado^

I run the testSimpleAccess from the testsuite, like you can see above. Another test cases resulted almost the same, with always the same assertion from my previous post.
Sorry the text format appeared wrong.

Philipe
phireis
 
Posts: 12
Joined: 21 Oct 2006, 03:18

Re: Re: Poco::Data::ODBC with PostgreSql assertion

Postby alex » 09 Oct 2007, 14:38

> Assertion violation: sizeof(_connectionName) > none.length() [in file "include/Poco/Data/ODBC/Diagnostics.h", line 181]

Your problem is likely due to this bug. The bug apparently slipped into 1.3.1. without being fixed.

To work around it either

__(a)__ change the declarations for 'none' and 'na' variables in Diagnostics::diagnostics() to declare strings, not references :

Code: Select all

static const std::string none = "None";
static const std::string na = "Not applicable";


or

__(b)__ check out the most recent subversion code (I have just tested PostgreSQL on Ubuntu and all 55 tests pass).

Warning: in the svn code, the default PostgreSQL ODBC driver for tests is [https://projects.commandprompt.com/public/odbcng/ | Mammoth ODBCng]. So, to successfully run the tests, either

*''(b.1)'' install ODBCng

or

*''(b.2)'' force use of psqlODBC by commenting the line 48 in ODBCPostgreSQL.h:

~~#009900:
Code: Select all

//#define POCO_ODBC_USE_MAMMOTH_NG

~~

Let me know if this works.

Alex
alex
 
Posts: 1143
Joined: 11 Jul 2006, 16:27
Location: United_States

Re: Re: Re: Poco::Data::ODBC with PostgreSql assertion

Postby alex » 09 Oct 2007, 14:44

> *''(b.2)'' force use of psqlODBC by commenting the line 48 in ODBCPostgreSQL.h:

The correct file name is __ODBCPostgreSQLTest.h__.
alex
 
Posts: 1143
Joined: 11 Jul 2006, 16:27
Location: United_States

Re: Re: Re: Poco::Data::ODBC with PostgreSql assertion

Postby phireis » 10 Oct 2007, 01:26

I changed the Diagnostics.h as you said on (a):


> __(a)__ change the declarations for 'none' and 'na' variables in Diagnostics::diagnostics() to declare strings, not references :
>
>
Code: Select all

> static const std::string none = "None";
> static const std::string na = "Not applicable";
>




Very good. Almost all the tests were sucefull. The only ones that failed were 3:
* testBareboneODBC
* testBLOB
* testBLOBStmt

The failures description are below:

Code: Select all

testBareboneODBC: FAILURE
!!!FAILURES!!!
Runs: 1   Failures: 1   Errors: 0
There was 1 failure:
 1: N7CppUnit10TestCallerI18ODBCPostgreSQLTestEE.testBareboneODBC
    "SQL_NEED_DATA == rc || SQL_SUCCEEDED(rc)"
    in "src/SQLExecutor.cpp", line 312


testBLOB: ODBC Error: ODBC handle exception
===================
Connection:Not applicable
Server:postgres-test
===========================
ODBC Diagnostic record #1:
===========================
SQLSTATE = 42704
Native Error Code = 7
Error while executing the query;
ERRO:  tipo "lo" não existe
LINE 1: ...PERSON VALUES ('lastname','firstname','Address','16755'::lo)
                                                                    ^



FAILURE

!!!FAILURES!!!
Runs: 1   Failures: 1   Errors: 0

There was 1 failure:
 1: N7CppUnit10TestCallerI18ODBCPostgreSQLTestEE.testBLOB
    "fail: blob()"
    in "", line -1


testBLOBStmt: ERROR

!!!FAILURES!!!
Runs: 1   Failures: 0   Errors: 1

There was 1 error:
 1: N7CppUnit10TestCallerI18ODBCPostgreSQLTestEE.testBLOBStmt
    "N4Poco4Data4ODBC15HandleExceptionIPvLs3EEE: ODBC handle exception"
    in "", line -1



Thanks, I'll test subversion code or 1.4,


Philipe
phireis
 
Posts: 12
Joined: 21 Oct 2006, 03:18

Re: Poco::Data::ODBC with PostgreSql assertion

Postby alex » 10 Oct 2007, 03:36

> Very good. Almost all the tests were sucefull. The only ones that failed were 3:
> * testBareboneODBC
> * testBLOB
> * testBLOBStmt

This is not the library problem any more - it is on the database side. You do not have the large object ('lo') datatype defined. If you do not need blobs, you may safely disregard these test failures. If you need blobs, you will have to define the lo datatype. I think this should suffice:

Code: Select all

create domain lo as oid;


Alex
alex
 
Posts: 1143
Joined: 11 Jul 2006, 16:27
Location: United_States


Return to Support

Who is online

Users browsing this forum: No registered users and 4 guests