gmane.comp.db.postgresql.odbc

Configure script unable to find PgSQL dir

Joe Tseng — 2012-05-23T13:56:43

I'm attempting to compile and install this from source but I'm getting a "library not found" error:

# ls -l /export/appl/pkgs/pgsql
total 4
lrwxrwxrwx   1 root     other          6 May 23 09:29 latest -> v9.1.3
drwxr-xr-x   6 root     other        512 May  8 16:02 v9.1.3

./configure \
  --prefix=/export/appl/pkgs/psqlodbc/v09.01.0100 \
  --with-libpq=/export/appl/pkgs/pgsql/latest \
  --with-unixodbc=/export/appl/pkgs/unixodbc/latest \
  --enable-unicode \
  --host=sparc-sun-solaris2.10 \
  --disable-openssl
...
checking for PQconnectdb in -lpq... no
configure: error: libpq library not found

I also configured using --without-libpq and the package was made and installed correctly, but I don't think it knows how to connect:

# ./isql pidcim11 odbcuser xxx
[ISQL]ERROR: Could not SQLConnect

If this is not the right address to ask questions is there a forum that I can post my problem to?

thx,

 - Joe


If you type "Google" into Google, you can break the Internet.  -- Jen Barber

[ psqlodbc-Bugs-1011196 ] Cannot insert very large blobs

2012-05-22T14:13:34

Bugs item #1011196, was opened at 2012-05-21 21:57
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1011196&group_id=1000125

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Michael Vitale (pgdude)
Assigned to: Nobody (None)
Summary: Cannot insert very large blobs

Initial Comment:
I can use the PostgreSQL ODBC driver to insert a blob (bytea) of 128 megabytes, but when I try to insert one that is 399 megabytes it fails with:

Query buffer overflow in copy_statement_with_parameters

The actuall call that fails is SQLExecute.


Here is the snippet of code I see in convert.c:

enlarge_query_statement(QueryBuild *qb, size_t newsize)
{
size_tnewalsize = INIT_MIN_ALLOC;
CSTR func = "enlarge_statement";

if (qb->str_size_limit > 0 && qb->str_size_limit < (int) newsize)
{
         < here is the branch that is executed>

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

Comment By: Michael Vitale (pgdude)
Date: 2012-05-21 22:13

Message:
[4272-42.487]SQL_VARBINARY: about to call
convert_to_pgbinary, used = 399966009
[4272-42.488]STATEMENT ERROR: func=enlarge_statement,
desc='', errnum=1, errmsg='Query buffer allocate error in
copy_statement_with_parameters'
[4272-42.496]CONN ERROR: func=enlarge_statement, desc='',
errnum=0, errmsg='(NULL)'
[4272-42.499]retval=-1
[4272-42.500][[SQLGetDiagFieldW]] Handle=(3,08F47DD0) Rec=1
Id=4 info=(09BF6788,12)
[4272-42.500]PGAPI_GetDiagField entering
rec=1[4272-42.500]ER_ReturnError: status = 1, msg = #Query
buffer allocate error in copy_statement_with_parameters#
[4272-42.501]         szSqlState = 'HY000',len=61,
szError='(null)'
[4272-42.501]PGAPI_GetDiagField exiting 0
[4272-42.502][[SQLGetDiagFieldW]] Handle=(3,08F47DD0) Rec=2
Id=4 info=(09BF6788,12)
[4272-42.502]PGAPI_GetDiagField entering
rec=2[4272-42.502]ER_ReturnError: status =


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

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1011196&group_id=1000125

[ psqlodbc-Bugs-1011196 ] Cannot insert very large blobs

2012-05-22T14:13:04

Bugs item #1011196, was opened at 2012-05-21 21:57
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1011196&group_id=1000125

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Michael Vitale (pgdude)
Assigned to: Nobody (None)
Summary: Cannot insert very large blobs

Initial Comment:
I can use the PostgreSQL ODBC driver to insert a blob (bytea) of 128 megabytes, but when I try to insert one that is 399 megabytes it fails with:

Query buffer overflow in copy_statement_with_parameters

The actuall call that fails is SQLExecute.


Here is the snippet of code I see in convert.c:

enlarge_query_statement(QueryBuild *qb, size_t newsize)
{
size_tnewalsize = INIT_MIN_ALLOC;
CSTR func = "enlarge_statement";

if (qb->str_size_limit > 0 && qb->str_size_limit < (int) newsize)
{
         < here is the branch that is executed>

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

Comment By: Michael Vitale (pgdude)
Date: 2012-05-21 22:13

Message:
[4272-42.487]SQL_VARBINARY: about to call
convert_to_pgbinary, used = 399966009
[4272-42.488]STATEMENT ERROR: func=enlarge_statement,
desc='', errnum=1, errmsg='Query buffer allocate error in
copy_statement_with_parameters'
[4272-42.496]CONN ERROR: func=enlarge_statement, desc='',
errnum=0, errmsg='(NULL)'
[4272-42.499]retval=-1
[4272-42.500][[SQLGetDiagFieldW]] Handle=(3,08F47DD0) Rec=1
Id=4 info=(09BF6788,12)
[4272-42.500]PGAPI_GetDiagField entering
rec=1[4272-42.500]ER_ReturnError: status = 1, msg = #Query
buffer allocate error in copy_statement_with_parameters#
[4272-42.501]         szSqlState = 'HY000',len=61,
szError='(null)'
[4272-42.501]PGAPI_GetDiagField exiting 0
[4272-42.502][[SQLGetDiagFieldW]] Handle=(3,08F47DD0) Rec=2
Id=4 info=(09BF6788,12)
[4272-42.502]PGAPI_GetDiagField entering
rec=2[4272-42.502]ER_ReturnError: status =


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

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1011196&group_id=1000125

cannot copy very large bytea data

Michael Vitale — 2012-05-22T13:57:29

I am able to copy a row with a 127megabyte column, but not with one that is 399 megabytes.

Here is the log output of the one that fails:

[4272-42.487]SQL_VARBINARY: about to call convert_to_pgbinary, used = 399966009
[4272-42.488]STATEMENT ERROR: func=enlarge_statement, desc='', errnum=1, errmsg='Query buffer allocate error in copy_statement_with_parameters'
[4272-42.496]CONN ERROR: func=enlarge_statement, desc='', errnum=0, errmsg='(NULL)'
[4272-42.499]retval=-1
[4272-42.500][[SQLGetDiagFieldW]] Handle=(3,08F47DD0) Rec=1 Id=4 info=(09BF6788,12)
[4272-42.500]PGAPI_GetDiagField entering rec=1[4272-42.500]ER_ReturnError: status = 1, msg = #Query buffer allocate error in copy_statement_with_parameters#
[4272-42.501]         szSqlState = 'HY000',len=61, szError='(null)'
[4272-42.501]PGAPI_GetDiagField exiting 0

[ psqlodbc-Bugs-1011196 ] Cannot insert very large blobs

2012-05-21T22:13:19

Bugs item #1011196, was opened at 2012-05-21 21:57
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1011196&group_id=1000125

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Michael Vitale (pgdude)
Assigned to: Nobody (None)
Summary: Cannot insert very large blobs

Initial Comment:
I can use the PostgreSQL ODBC driver to insert a blob (bytea) of 128 megabytes, but when I try to insert one that is 399 megabytes it fails with:

Query buffer overflow in copy_statement_with_parameters

The actuall call that fails is SQLExecute.


Here is the snippet of code I see in convert.c:

enlarge_query_statement(QueryBuild *qb, size_t newsize)
{
size_tnewalsize = INIT_MIN_ALLOC;
CSTR func = "enlarge_statement";

if (qb->str_size_limit > 0 && qb->str_size_limit < (int) newsize)
{
         < here is the branch that is executed>

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

Date: 2012-05-21 22:13

Message:
[4272-42.487]SQL_VARBINARY: about to call
convert_to_pgbinary, used = 399966009
[4272-42.488]STATEMENT ERROR: func=enlarge_statement,
desc='', errnum=1, errmsg='Query buffer allocate error in
copy_statement_with_parameters'
[4272-42.496]CONN ERROR: func=enlarge_statement, desc='',
errnum=0, errmsg='(NULL)'
[4272-42.499]retval=-1
[4272-42.500][[SQLGetDiagFieldW]] Handle=(3,08F47DD0) Rec=1
Id=4 info=(09BF6788,12)
[4272-42.500]PGAPI_GetDiagField entering
rec=1[4272-42.500]ER_ReturnError: status = 1, msg = #Query
buffer allocate error in copy_statement_with_parameters#
[4272-42.501]         szSqlState = 'HY000',len=61,
szError='(null)'
[4272-42.501]PGAPI_GetDiagField exiting 0
[4272-42.502][[SQLGetDiagFieldW]] Handle=(3,08F47DD0) Rec=2
Id=4 info=(09BF6788,12)
[4272-42.502]PGAPI_GetDiagField entering
rec=2[4272-42.502]ER_ReturnError: status =


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

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1011196&group_id=1000125

[ psqlodbc-Bugs-1011196 ] Cannot insert very large blobs

2012-05-21T21:57:28

Bugs item #1011196, was opened at 2012-05-21 21:57
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1011196&group_id=1000125

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Michael Vitale (pgdude)
Assigned to: Nobody (None)
Summary: Cannot insert very large blobs

Initial Comment:
I can use the PostgreSQL ODBC driver to insert a blob (bytea) of 128 megabytes, but when I try to insert one that is 399 megabytes it fails with:

Query buffer overflow in copy_statement_with_parameters

The actuall call that fails is SQLExecute.


Here is the snippet of code I see in convert.c:

enlarge_query_statement(QueryBuild *qb, size_t newsize)
{
size_tnewalsize = INIT_MIN_ALLOC;
CSTR func = "enlarge_statement";

if (qb->str_size_limit > 0 && qb->str_size_limit < (int) newsize)
{
         < here is the branch that is executed>

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

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1011196&group_id=1000125

Update For Outdated Win98

BGoebel — 2012-05-08T11:38:07

I admit, nowadays an exotic szenario:

Running a PostgreSQL client on an Windows 98 machine.

The 9.1 pSQLOdbc Driver uses some Kernel32.DLL functions which were
introduced with  WindowsXP.
such as TryEnterCriticalSection().

I updated Windows 98 with KernelEx 4.5.2 http://kernelex.sourceforge.net/
and the brandnew 2011 pSQLOdbc driver runs with our application without a
problem until now. We are using UTF8 Charsets with the psqlodbca.dll, UTF 16
with psqlodbcw.dll might be an issue.

KernelEx is a compatibility layer for running Win2000+ apps.

I have tested it with Win98 running in a VM, but i am sure pSQLODBC will
work with a real machine too.

Special thanks go to Hiroshi Inoue for his hint.
 




--
View this message in context: http://postgresql.1045698.n5.nabble.com/Update-For-Outdated-Win98-tp5693458.html
Sent from the PostgreSQL - odbc mailing list archive at Nabble.com.

Advanced Options - OID

Jan-Peter Seifert — 2012-04-23T11:21:59

Hello,

if 'Advanced Options' -> 'OID Options' -> 'Show Column' is activated ODBC
function SQLColumns() retrieves one more row than expected if you use the function's filter ColumnName.
If you check for the existence of a column that does not exist you get one
instead of no result row.
If you check for the existence of a column that does exist you get two instead of one row and the correct row is the second and not the first one.

Could you check this, please?

Thank you very much,

Peter Seifert

UPDATE table via ODBC fails.

Ken Benson — 2012-04-11T22:01:36

I have a fairly straightforward routine which uses an ODBC connection to 
do 4 steps:

  * DROP TABLE IF EXISTS tmp_rxpurge
  * CREATE TABLE tmp_rxpurge (rxnum VARCHAR(300),dt_wrt DATE,dt_lastfill
    DATE,dt_lastact DATE, b_purge BOOLEAN)
  * INSERT INTO tmp_rxpurge (rxnum,dt_wrt,b_purge) SELECT
    "RXNUM","DATE",'f' FROM rx
  * UPDATE tmp_rxpurge as t SET dt_lastfill = rf.dt_lastfill FROM
    (SELECT "RXNUM" AS rxnum, Max("DATE") as dt_lastfill FROM
    transactions GROUP BY "RXNUM") as rf WHERE rf.rxnum=t.rxnum


The first three commands are executed perfectly as expected.
The update fails to do anything.
There is no error generated.
I have enabled 'logging' in the ODBC connector - and I don't see 
anything out of the ordinary in the short-log. (The long-log - I have no 
idea what all that stuff means.)

If I copy that last command into a psql window - it executes - and works 
fine.

But - it will not work via the ODBC connector.

What's going on?

Ken

Passing numeric Bind variables to ODBC driver convers to "Double precision"

Barry Bell — 2012-04-09T14:35:10

 Using the lastest of ODBC ANSI driver for windows 32bit ver 9.00.03  Calling from MS VFP 9.0

 public nvar as interger
 nvar=1
 running the following sql:
 "( select function_pkg(?nvar) "

 The bind variable nvar will show in postgres as "Double Precision"  format instead of integer(or numeric)

 Is there a setting on the ODBC driver for incoming vairables?

Very basic question from a beginner

Jean MAURICE — 2012-04-08T14:03:10

HI,

I am very new to PostGreSql and ODBC but an 'expert' in Visual Foxpro. I wanted 
to try VFP as a client of PostGres. My laptop is under W7-64. I 'installed' the 
ODBC driver via Stack Builder. All things seemed to work well but nothing 
appears in th ODBC Sources Manager (I apologize I must guess the english names 
from the french ones ...).

What have I missed ?

Thanks in advance.
Best regards
The Foxil

[ psqlodbc-Bugs-1010500 ] UUID not being returned correctly

2012-03-28T03:28:24

Bugs item #1010500, was opened at 2008-10-28 14:09
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1010500&group_id=1000125

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Philip Warner (pjw)
Assigned to: Nobody (None)
Summary: UUID not being returned correctly

Initial Comment:

I have the following in a postgres 8.3 DB:

Create Table test(f uuid);
insert into test values('e964684f-87fe-49d9-9b87-137cc83165ea');

I have the following VB.Net 2005 code that connects to this DB (using either ANSI or UNICODE driver); full connection string below. I use a DataAdapter as follows:

  Dim c As New ODBC.ODBCConnection(My.Settings.ConnectionString)
  Dim DA As New Odbc.OdbcDataAdapter("select f::text, f from test", c)
  Dim Tbl As New DataTable
  DA.Fill(zTbl)

When I inspect the values, they differ:

  ?tbl.Rows(0).Item(0).ToString
  "e964684f-87fe-49d9-9b87-137cc83165ea"
  ?tbl.Rows(0).Item(1).ToString
  "00390065-0036-0034-3600-380034006600"

The original can be stored using the ODBC driver, it just seems to have trouble retrieving it.



Full connection string:

Driver={PostgreSQL ANSI};database=time_log;server=xxx.yyy.zzz.ttt;port=5433;uid=root;sslmode=allow;readonly=0;protocol=7.4-1;fakeoidindex=0;showoidcolumn=0;rowversioning=0;showsystemtables=0;fetch=100;socket=4096;unknownsizes=0;maxvarcharsize=255;maxlongvarcharsize=8190;debug=0;commlog=0;optimizer=0;ksqo=1;usedeclarefetch=0;textaslongvarchar=1;unknownsaslongvarchar=0;boolsaschar=0;parse=0;cancelasfreestmt=0;extrasystableprefixes=dd_;lfconversion=1;updatablecursors=0;disallowpremature=0;trueisminus1=1;bi=0;byteaaslongvarbinary=0;useserversideprepare=0;lowercaseidentifier=0;xaopt=1



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

Date: 2012-03-28 03:28

Message:
Oops, I've misunderstood the log info.

Did you display all Mylog output?
ISTM the log only contains the connection phase.

regards,
Hiroshi Inoue

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

Comment By: Nicolas Helleringer (nhe)
Date: 2012-03-27 13:41

Message:
This is what I did.

The log I posted is the content of the C:\Mylog_xxx.log file

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

Comment By: Hiroshi Inoue (hinoue)
Date: 2012-03-27 11:36

Message:
At the PostgreSQL Unicode/ANSI ODBC Driver (psqlODBC) Setup
 page, click the Datasource button and you can find the
 MyLog (C:\mylog_xxxx.log) check box.

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

Comment By: Nicolas Helleringer (nhe)
Date: 2012-03-26 09:02

Message:
I don't understand

The log is the Mylgog for the DSN UUIDTest created for the test.

I do not know what you mean by or how to "turn on per DSN Mylog option" sorry

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

Comment By: Hiroshi Inoue (hinoue)
Date: 2012-03-24 15:09

Message:
Please turn on per DSN Mylog option as well.

regards,
Hiroshi inoue

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

Comment By: Nicolas Helleringer (nhe)
Date: 2012-03-23 13:39

Message:
Here you are :

[5928-0.000]CC_connect: entering...
[5928-0.001]sslmode=disable
[5928-0.001]original_CC_connect: entering...
[5928-0.003]Driver Version='09.01.0100,201112290002' linking 1400 dynamic Multithread library
[5928-0.011]original_CC_connect: DSN = 'UUIDTest', server = 'X.X.X.X', port = '5432', database = 'UUIDTest', username = 'access', password='xxxxx'
[5928-0.013]connecting to the server socket...
[5928-0.015](0)(null) ERRNO=0
[5928-0.016]connection to the server socket succeeded.
[5928-0.017]!!! usrname=access server=X.X.X.X
[5928-0.017]startup client_encoding=UTF8
[5928-0.018]sizeof startup packet = 97
[5928-0.019]sent the authentication block successfully.
[5928-0.019]gonna do authentication
[5928-0.019]read -1, global_socket_buffersize=4096
[5928-0.019]Lasterror=10035
[5928-0.070]read 13, global_socket_buffersize=4096
[5928-0.070]auth got 'R'
[5928-0.070]areq = 5 salt=b576b1d400
[5928-0.071]in AUTH_REQ_MD5
[5928-0.071]read -1, global_socket_buffersize=4096
[5928-0.071]Lasterror=10035
[5928-0.097]read 324, global_socket_buffersize=4096
[5928-0.097]auth got 'R'
[5928-0.097]areq = 0 salt=0000000000
[5928-0.097]auth got 'S'
[5928-0.097]auth got 'S'
[5928-0.097]auth got 'S'
[5928-0.097]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]Got the PostgreSQL version string: '9.0.3'
[5928-0.098]Extracted PostgreSQL version number: '9.0'
[5928-0.100]auth got 'S'
[5928-0.100]auth got 'S'
[5928-0.100]standard_conforming_strings=off
[5928-0.101]auth got 'S'
[5928-0.101]auth got 'K'
[5928-0.101]auth got 'Z'
[5928-0.101]CC_send_settings: entering...
[5928-0.101]PGAPI_AllocStmt: entering...
[5928-0.102]**** PGAPI_AllocStmt: hdbc = 00000000001BC460, stmt = 00000000001BF820
[5928-0.102]CC_add_statement: self=00000000001BC460, stmt=00000000001BF820
[5928-0.102]PGAPI_FreeStmt: entering...hstmt=00000000001BF820, fOption=1
[5928-0.103]QResult: enter DESTRUCTOR
[5928-0.103]SC_init_Result(1bf820)[5928-0.103]SC_Destructor: self=00000000001BF820, self->result=0000000000000000, self->hdbc=00000000001BC460
[5928-0.104]APD_free_params:  ENTER, self=00000000001BF9C8
[5928-0.104]IPD_free_params:  ENTER, self=00000000001BFA38
[5928-0.104]PDATA_free_params:  ENTER, self=00000000001BFB00
[5928-0.105]SC_Destructor: EXIT
[5928-0.105]CC_lookup_lo: entering...
[5928-0.105]CC_send_query: conn=00000000001BC460, query='select oid, typbasetype from pg_type where typname = 'lo''
[5928-0.106]send_query: done sending query 63bytes flushed
[5928-0.107]in QR_Constructor
[5928-0.107]exit QR_Constructor
[5928-0.107]read -1, global_socket_buffersize=4096
[5928-0.107]Lasterror=10035
[5928-0.133]read 79, global_socket_buffersize=4096
[5928-0.133]send_query: got id = 'T'
[5928-0.133]QR_fetch_tuples: cursor = '', self->cursor=0000000000000000
[5928-0.134]num_fields = 2
[5928-0.134]READING ATTTYPMOD
[5928-0.134]CI_read_fields: fieldname='oid', adtid=26, adtsize=4, atttypmod=-1 (rel,att)=(1247,65534)
[5928-0.135]READING ATTTYPMOD
[5928-0.135]CI_read_fields: fieldname='typbasetype', adtid=26, adtsize=4, atttypmod=-1 (rel,att)=(1247,24)
[5928-0.135]QR_fetch_tuples: past CI_read_fields: num_fields = 2
[5928-0.136]MALLOC: tuple_size = 100, size = 3200
[5928-0.136]QR_next_tuple: inTuples = true, falling through: fcount = 0, fetch_number = 0
[5928-0.136]end of tuple list -- setting inUse to false: this = 00000000001BF820 SELECT 0
[5928-0.137]_QR_next_tuple: 'C' fetch_total = 0 & this_fetch = 0
[5928-0.137]QR_next_tuple: backend_rows < CACHE_SIZE: brows = 0, cache_size = 0
[5928-0.138]QR_next_tuple: reached eof now
[5928-0.138]_QR_next_tuple: 'C': DONE (fcount == 0)
[5928-0.138]send_query: got id = 'Z'
[5928-0.139]QResult: enter DESTRUCTOR
[5928-0.139]QResult: in QR_close_result
[5928-0.139]QResult: free memory in, fcount=0
[5928-0.139]QResult: free memory out
[5928-0.139]QResult: enter DESTRUCTOR
[5928-0.140]QResult: exit close_result
[5928-0.140]QResult: exit DESTRUCTOR
[5928-0.140]Got the large object oid: -999
[5928-0.140]CC_lookup_characterset: entering...
[5928-0.141]conn->unicode=1
[5928-0.141]CC_connect: returning...1


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

Comment By: Hiroshi Inoue (hinoue)
Date: 2012-03-22 23:48

Message:
Hi Nicolas,

I cannot reproduce the case with MS Access 2002.
Could you attach the Mylog output of your case?

regards,
Hiroshi Inoue


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

Comment By: Nicolas Helleringer (nhe)
Date: 2012-03-20 15:26

Message:
Done the same on a x86 32 bits host / Access / ODBC driver

Same results, GUID are not well transfered.

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

Comment By: Nicolas Helleringer (nhe)
Date: 2012-03-20 14:10

Message:
Same bug here with the x64 latest driver version (2011-12-30 version)

Context :
- From MS Access 2010 64 bits
- Replication number field GUID
- Export table to ODBC tool

With the unicode driver the tables are created correctly i-e fields are mapped to uuid fields (with ansi version they are mapped to bytea fields) but data in them is not ok.

Source is GUID like : {7AB02082-2242-4A65-A7E3-6B624BF4873E}

Transfered data is like :  00410037-0042-0030-3200-300038003200

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

Comment By: Philip Warner (pjw)
Date: 2008-11-01 12:14

Message:
Thanks for the quick response!

I tried the ASCII driver, and it worked, which is great!

How stable are the beta drivers? and/or any schedule for
releasing a production version?

Thanks again.



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

Comment By: Hiroshi Inoue (hinoue)
Date: 2008-10-31 22:04

Message:
Could you try the drivers on testing for 8.3.0300 dll at
 http://www.geocities.jp/inocchichichi/psqlodbc/index.html
?

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

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1010500&group_id=1000125

[ psqlodbc-Bugs-1010500 ] UUID not being returned correctly

2012-03-27T13:41:37

Bugs item #1010500, was opened at 28/10/2008 15:09
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1010500&group_id=1000125

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Philip Warner (pjw)
Assigned to: Nobody (None)
Summary: UUID not being returned correctly

Initial Comment:

I have the following in a postgres 8.3 DB:

Create Table test(f uuid);
insert into test values('e964684f-87fe-49d9-9b87-137cc83165ea');

I have the following VB.Net 2005 code that connects to this DB (using either ANSI or UNICODE driver); full connection string below. I use a DataAdapter as follows:

  Dim c As New ODBC.ODBCConnection(My.Settings.ConnectionString)
  Dim DA As New Odbc.OdbcDataAdapter("select f::text, f from test", c)
  Dim Tbl As New DataTable
  DA.Fill(zTbl)

When I inspect the values, they differ:

  ?tbl.Rows(0).Item(0).ToString
  "e964684f-87fe-49d9-9b87-137cc83165ea"
  ?tbl.Rows(0).Item(1).ToString
  "00390065-0036-0034-3600-380034006600"

The original can be stored using the ODBC driver, it just seems to have trouble retrieving it.



Full connection string:

Driver={PostgreSQL ANSI};database=time_log;server=xxx.yyy.zzz.ttt;port=5433;uid=root;sslmode=allow;readonly=0;protocol=7.4-1;fakeoidindex=0;showoidcolumn=0;rowversioning=0;showsystemtables=0;fetch=100;socket=4096;unknownsizes=0;maxvarcharsize=255;maxlongvarcharsize=8190;debug=0;commlog=0;optimizer=0;ksqo=1;usedeclarefetch=0;textaslongvarchar=1;unknownsaslongvarchar=0;boolsaschar=0;parse=0;cancelasfreestmt=0;extrasystableprefixes=dd_;lfconversion=1;updatablecursors=0;disallowpremature=0;trueisminus1=1;bi=0;byteaaslongvarbinary=0;useserversideprepare=0;lowercaseidentifier=0;xaopt=1



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

Comment By: Nicolas Helleringer (nhe)
Date: 27/03/2012 15:41

Message:
This is what I did.

The log I posted is the content of the C:\Mylog_xxx.log file

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

Comment By: Hiroshi Inoue (hinoue)
Date: 27/03/2012 13:36

Message:
At the PostgreSQL Unicode/ANSI ODBC Driver (psqlODBC) Setup
 page, click the Datasource button and you can find the
 MyLog (C:\mylog_xxxx.log) check box.

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

Comment By: Nicolas Helleringer (nhe)
Date: 26/03/2012 11:02

Message:
I don't understand

The log is the Mylgog for the DSN UUIDTest created for the test.

I do not know what you mean by or how to "turn on per DSN Mylog option" sorry

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

Comment By: Hiroshi Inoue (hinoue)
Date: 24/03/2012 16:09

Message:
Please turn on per DSN Mylog option as well.

regards,
Hiroshi inoue

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

Comment By: Nicolas Helleringer (nhe)
Date: 23/03/2012 14:39

Message:
Here you are :

[5928-0.000]CC_connect: entering...
[5928-0.001]sslmode=disable
[5928-0.001]original_CC_connect: entering...
[5928-0.003]Driver Version='09.01.0100,201112290002' linking 1400 dynamic Multithread library
[5928-0.011]original_CC_connect: DSN = 'UUIDTest', server = 'X.X.X.X', port = '5432', database = 'UUIDTest', username = 'access', password='xxxxx'
[5928-0.013]connecting to the server socket...
[5928-0.015](0)(null) ERRNO=0
[5928-0.016]connection to the server socket succeeded.
[5928-0.017]!!! usrname=access server=X.X.X.X
[5928-0.017]startup client_encoding=UTF8
[5928-0.018]sizeof startup packet = 97
[5928-0.019]sent the authentication block successfully.
[5928-0.019]gonna do authentication
[5928-0.019]read -1, global_socket_buffersize=4096
[5928-0.019]Lasterror=10035
[5928-0.070]read 13, global_socket_buffersize=4096
[5928-0.070]auth got 'R'
[5928-0.070]areq = 5 salt=b576b1d400
[5928-0.071]in AUTH_REQ_MD5
[5928-0.071]read -1, global_socket_buffersize=4096
[5928-0.071]Lasterror=10035
[5928-0.097]read 324, global_socket_buffersize=4096
[5928-0.097]auth got 'R'
[5928-0.097]areq = 0 salt=0000000000
[5928-0.097]auth got 'S'
[5928-0.097]auth got 'S'
[5928-0.097]auth got 'S'
[5928-0.097]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]Got the PostgreSQL version string: '9.0.3'
[5928-0.098]Extracted PostgreSQL version number: '9.0'
[5928-0.100]auth got 'S'
[5928-0.100]auth got 'S'
[5928-0.100]standard_conforming_strings=off
[5928-0.101]auth got 'S'
[5928-0.101]auth got 'K'
[5928-0.101]auth got 'Z'
[5928-0.101]CC_send_settings: entering...
[5928-0.101]PGAPI_AllocStmt: entering...
[5928-0.102]**** PGAPI_AllocStmt: hdbc = 00000000001BC460, stmt = 00000000001BF820
[5928-0.102]CC_add_statement: self=00000000001BC460, stmt=00000000001BF820
[5928-0.102]PGAPI_FreeStmt: entering...hstmt=00000000001BF820, fOption=1
[5928-0.103]QResult: enter DESTRUCTOR
[5928-0.103]SC_init_Result(1bf820)[5928-0.103]SC_Destructor: self=00000000001BF820, self->result=0000000000000000, self->hdbc=00000000001BC460
[5928-0.104]APD_free_params:  ENTER, self=00000000001BF9C8
[5928-0.104]IPD_free_params:  ENTER, self=00000000001BFA38
[5928-0.104]PDATA_free_params:  ENTER, self=00000000001BFB00
[5928-0.105]SC_Destructor: EXIT
[5928-0.105]CC_lookup_lo: entering...
[5928-0.105]CC_send_query: conn=00000000001BC460, query='select oid, typbasetype from pg_type where typname = 'lo''
[5928-0.106]send_query: done sending query 63bytes flushed
[5928-0.107]in QR_Constructor
[5928-0.107]exit QR_Constructor
[5928-0.107]read -1, global_socket_buffersize=4096
[5928-0.107]Lasterror=10035
[5928-0.133]read 79, global_socket_buffersize=4096
[5928-0.133]send_query: got id = 'T'
[5928-0.133]QR_fetch_tuples: cursor = '', self->cursor=0000000000000000
[5928-0.134]num_fields = 2
[5928-0.134]READING ATTTYPMOD
[5928-0.134]CI_read_fields: fieldname='oid', adtid=26, adtsize=4, atttypmod=-1 (rel,att)=(1247,65534)
[5928-0.135]READING ATTTYPMOD
[5928-0.135]CI_read_fields: fieldname='typbasetype', adtid=26, adtsize=4, atttypmod=-1 (rel,att)=(1247,24)
[5928-0.135]QR_fetch_tuples: past CI_read_fields: num_fields = 2
[5928-0.136]MALLOC: tuple_size = 100, size = 3200
[5928-0.136]QR_next_tuple: inTuples = true, falling through: fcount = 0, fetch_number = 0
[5928-0.136]end of tuple list -- setting inUse to false: this = 00000000001BF820 SELECT 0
[5928-0.137]_QR_next_tuple: 'C' fetch_total = 0 & this_fetch = 0
[5928-0.137]QR_next_tuple: backend_rows < CACHE_SIZE: brows = 0, cache_size = 0
[5928-0.138]QR_next_tuple: reached eof now
[5928-0.138]_QR_next_tuple: 'C': DONE (fcount == 0)
[5928-0.138]send_query: got id = 'Z'
[5928-0.139]QResult: enter DESTRUCTOR
[5928-0.139]QResult: in QR_close_result
[5928-0.139]QResult: free memory in, fcount=0
[5928-0.139]QResult: free memory out
[5928-0.139]QResult: enter DESTRUCTOR
[5928-0.140]QResult: exit close_result
[5928-0.140]QResult: exit DESTRUCTOR
[5928-0.140]Got the large object oid: -999
[5928-0.140]CC_lookup_characterset: entering...
[5928-0.141]conn->unicode=1
[5928-0.141]CC_connect: returning...1


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

Comment By: Hiroshi Inoue (hinoue)
Date: 23/03/2012 00:48

Message:
Hi Nicolas,

I cannot reproduce the case with MS Access 2002.
Could you attach the Mylog output of your case?

regards,
Hiroshi Inoue


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

Comment By: Nicolas Helleringer (nhe)
Date: 20/03/2012 16:26

Message:
Done the same on a x86 32 bits host / Access / ODBC driver

Same results, GUID are not well transfered.

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

Comment By: Nicolas Helleringer (nhe)
Date: 20/03/2012 15:10

Message:
Same bug here with the x64 latest driver version (2011-12-30 version)

Context :
- From MS Access 2010 64 bits
- Replication number field GUID
- Export table to ODBC tool

With the unicode driver the tables are created correctly i-e fields are mapped to uuid fields (with ansi version they are mapped to bytea fields) but data in them is not ok.

Source is GUID like : {7AB02082-2242-4A65-A7E3-6B624BF4873E}

Transfered data is like :  00410037-0042-0030-3200-300038003200

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

Comment By: Philip Warner (pjw)
Date: 01/11/2008 13:14

Message:
Thanks for the quick response!

I tried the ASCII driver, and it worked, which is great!

How stable are the beta drivers? and/or any schedule for
releasing a production version?

Thanks again.



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

Comment By: Hiroshi Inoue (hinoue)
Date: 31/10/2008 23:04

Message:
Could you try the drivers on testing for 8.3.0300 dll at
 http://www.geocities.jp/inocchichichi/psqlodbc/index.html
?

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

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1010500&group_id=1000125

[ psqlodbc-Bugs-1010500 ] UUID not being returned correctly

2012-03-27T11:36:35

Bugs item #1010500, was opened at 2008-10-28 14:09
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1010500&group_id=1000125

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Philip Warner (pjw)
Assigned to: Nobody (None)
Summary: UUID not being returned correctly

Initial Comment:

I have the following in a postgres 8.3 DB:

Create Table test(f uuid);
insert into test values('e964684f-87fe-49d9-9b87-137cc83165ea');

I have the following VB.Net 2005 code that connects to this DB (using either ANSI or UNICODE driver); full connection string below. I use a DataAdapter as follows:

  Dim c As New ODBC.ODBCConnection(My.Settings.ConnectionString)
  Dim DA As New Odbc.OdbcDataAdapter("select f::text, f from test", c)
  Dim Tbl As New DataTable
  DA.Fill(zTbl)

When I inspect the values, they differ:

  ?tbl.Rows(0).Item(0).ToString
  "e964684f-87fe-49d9-9b87-137cc83165ea"
  ?tbl.Rows(0).Item(1).ToString
  "00390065-0036-0034-3600-380034006600"

The original can be stored using the ODBC driver, it just seems to have trouble retrieving it.



Full connection string:

Driver={PostgreSQL ANSI};database=time_log;server=xxx.yyy.zzz.ttt;port=5433;uid=root;sslmode=allow;readonly=0;protocol=7.4-1;fakeoidindex=0;showoidcolumn=0;rowversioning=0;showsystemtables=0;fetch=100;socket=4096;unknownsizes=0;maxvarcharsize=255;maxlongvarcharsize=8190;debug=0;commlog=0;optimizer=0;ksqo=1;usedeclarefetch=0;textaslongvarchar=1;unknownsaslongvarchar=0;boolsaschar=0;parse=0;cancelasfreestmt=0;extrasystableprefixes=dd_;lfconversion=1;updatablecursors=0;disallowpremature=0;trueisminus1=1;bi=0;byteaaslongvarbinary=0;useserversideprepare=0;lowercaseidentifier=0;xaopt=1



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

Date: 2012-03-27 11:36

Message:
At the PostgreSQL Unicode/ANSI ODBC Driver (psqlODBC) Setup
 page, click the Datasource button and you can find the
 MyLog (C:\mylog_xxxx.log) check box.

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

Comment By: Nicolas Helleringer (nhe)
Date: 2012-03-26 09:02

Message:
I don't understand

The log is the Mylgog for the DSN UUIDTest created for the test.

I do not know what you mean by or how to "turn on per DSN Mylog option" sorry

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

Comment By: Hiroshi Inoue (hinoue)
Date: 2012-03-24 15:09

Message:
Please turn on per DSN Mylog option as well.

regards,
Hiroshi inoue

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

Comment By: Nicolas Helleringer (nhe)
Date: 2012-03-23 13:39

Message:
Here you are :

[5928-0.000]CC_connect: entering...
[5928-0.001]sslmode=disable
[5928-0.001]original_CC_connect: entering...
[5928-0.003]Driver Version='09.01.0100,201112290002' linking 1400 dynamic Multithread library
[5928-0.011]original_CC_connect: DSN = 'UUIDTest', server = 'X.X.X.X', port = '5432', database = 'UUIDTest', username = 'access', password='xxxxx'
[5928-0.013]connecting to the server socket...
[5928-0.015](0)(null) ERRNO=0
[5928-0.016]connection to the server socket succeeded.
[5928-0.017]!!! usrname=access server=X.X.X.X
[5928-0.017]startup client_encoding=UTF8
[5928-0.018]sizeof startup packet = 97
[5928-0.019]sent the authentication block successfully.
[5928-0.019]gonna do authentication
[5928-0.019]read -1, global_socket_buffersize=4096
[5928-0.019]Lasterror=10035
[5928-0.070]read 13, global_socket_buffersize=4096
[5928-0.070]auth got 'R'
[5928-0.070]areq = 5 salt=b576b1d400
[5928-0.071]in AUTH_REQ_MD5
[5928-0.071]read -1, global_socket_buffersize=4096
[5928-0.071]Lasterror=10035
[5928-0.097]read 324, global_socket_buffersize=4096
[5928-0.097]auth got 'R'
[5928-0.097]areq = 0 salt=0000000000
[5928-0.097]auth got 'S'
[5928-0.097]auth got 'S'
[5928-0.097]auth got 'S'
[5928-0.097]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]Got the PostgreSQL version string: '9.0.3'
[5928-0.098]Extracted PostgreSQL version number: '9.0'
[5928-0.100]auth got 'S'
[5928-0.100]auth got 'S'
[5928-0.100]standard_conforming_strings=off
[5928-0.101]auth got 'S'
[5928-0.101]auth got 'K'
[5928-0.101]auth got 'Z'
[5928-0.101]CC_send_settings: entering...
[5928-0.101]PGAPI_AllocStmt: entering...
[5928-0.102]**** PGAPI_AllocStmt: hdbc = 00000000001BC460, stmt = 00000000001BF820
[5928-0.102]CC_add_statement: self=00000000001BC460, stmt=00000000001BF820
[5928-0.102]PGAPI_FreeStmt: entering...hstmt=00000000001BF820, fOption=1
[5928-0.103]QResult: enter DESTRUCTOR
[5928-0.103]SC_init_Result(1bf820)[5928-0.103]SC_Destructor: self=00000000001BF820, self->result=0000000000000000, self->hdbc=00000000001BC460
[5928-0.104]APD_free_params:  ENTER, self=00000000001BF9C8
[5928-0.104]IPD_free_params:  ENTER, self=00000000001BFA38
[5928-0.104]PDATA_free_params:  ENTER, self=00000000001BFB00
[5928-0.105]SC_Destructor: EXIT
[5928-0.105]CC_lookup_lo: entering...
[5928-0.105]CC_send_query: conn=00000000001BC460, query='select oid, typbasetype from pg_type where typname = 'lo''
[5928-0.106]send_query: done sending query 63bytes flushed
[5928-0.107]in QR_Constructor
[5928-0.107]exit QR_Constructor
[5928-0.107]read -1, global_socket_buffersize=4096
[5928-0.107]Lasterror=10035
[5928-0.133]read 79, global_socket_buffersize=4096
[5928-0.133]send_query: got id = 'T'
[5928-0.133]QR_fetch_tuples: cursor = '', self->cursor=0000000000000000
[5928-0.134]num_fields = 2
[5928-0.134]READING ATTTYPMOD
[5928-0.134]CI_read_fields: fieldname='oid', adtid=26, adtsize=4, atttypmod=-1 (rel,att)=(1247,65534)
[5928-0.135]READING ATTTYPMOD
[5928-0.135]CI_read_fields: fieldname='typbasetype', adtid=26, adtsize=4, atttypmod=-1 (rel,att)=(1247,24)
[5928-0.135]QR_fetch_tuples: past CI_read_fields: num_fields = 2
[5928-0.136]MALLOC: tuple_size = 100, size = 3200
[5928-0.136]QR_next_tuple: inTuples = true, falling through: fcount = 0, fetch_number = 0
[5928-0.136]end of tuple list -- setting inUse to false: this = 00000000001BF820 SELECT 0
[5928-0.137]_QR_next_tuple: 'C' fetch_total = 0 & this_fetch = 0
[5928-0.137]QR_next_tuple: backend_rows < CACHE_SIZE: brows = 0, cache_size = 0
[5928-0.138]QR_next_tuple: reached eof now
[5928-0.138]_QR_next_tuple: 'C': DONE (fcount == 0)
[5928-0.138]send_query: got id = 'Z'
[5928-0.139]QResult: enter DESTRUCTOR
[5928-0.139]QResult: in QR_close_result
[5928-0.139]QResult: free memory in, fcount=0
[5928-0.139]QResult: free memory out
[5928-0.139]QResult: enter DESTRUCTOR
[5928-0.140]QResult: exit close_result
[5928-0.140]QResult: exit DESTRUCTOR
[5928-0.140]Got the large object oid: -999
[5928-0.140]CC_lookup_characterset: entering...
[5928-0.141]conn->unicode=1
[5928-0.141]CC_connect: returning...1


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

Comment By: Hiroshi Inoue (hinoue)
Date: 2012-03-22 23:48

Message:
Hi Nicolas,

I cannot reproduce the case with MS Access 2002.
Could you attach the Mylog output of your case?

regards,
Hiroshi Inoue


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

Comment By: Nicolas Helleringer (nhe)
Date: 2012-03-20 15:26

Message:
Done the same on a x86 32 bits host / Access / ODBC driver

Same results, GUID are not well transfered.

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

Comment By: Nicolas Helleringer (nhe)
Date: 2012-03-20 14:10

Message:
Same bug here with the x64 latest driver version (2011-12-30 version)

Context :
- From MS Access 2010 64 bits
- Replication number field GUID
- Export table to ODBC tool

With the unicode driver the tables are created correctly i-e fields are mapped to uuid fields (with ansi version they are mapped to bytea fields) but data in them is not ok.

Source is GUID like : {7AB02082-2242-4A65-A7E3-6B624BF4873E}

Transfered data is like :  00410037-0042-0030-3200-300038003200

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

Comment By: Philip Warner (pjw)
Date: 2008-11-01 12:14

Message:
Thanks for the quick response!

I tried the ASCII driver, and it worked, which is great!

How stable are the beta drivers? and/or any schedule for
releasing a production version?

Thanks again.



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

Comment By: Hiroshi Inoue (hinoue)
Date: 2008-10-31 22:04

Message:
Could you try the drivers on testing for 8.3.0300 dll at
 http://www.geocities.jp/inocchichichi/psqlodbc/index.html
?

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

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1010500&group_id=1000125

Handling of Arrays broken..?

Barend Köbben — 2012-03-27T08:30:11

Hi,

Since upgrading to PostgreSQL 9.1.2 and its psql-odbc driver (9.0.3.10),
the results of queries to arrays seems broken. I have an SQL 'items'
column of type character(3)[]. A 'normal' SQL query 'SELECT items FROM
table' results in a proper Array (shows in PgAdmin as {100,999,122} ).

In ASP JavaScript the same query done in an ADODB connection...

SQLcmd.CommandText = "SELECT items FROM table";
var RecSet = SQLcmd.Execute;

while (!RecSet.EOF && !RecSet.BOF) {
        var theItemsStr = RecSet.Fields.Item("items").Value;

...results in theItemsStr being '{10'

The same code worked in an earlier installation with Postgres 8.4 and its
driver (version?).


By accident I found that the same thing with the SQL "SELECT items[1:99]
FROM table" does work correctly (even if the array only has 3 items). Is
this a bug that has been introduced in the new version of the driver, or
is there something else I missed...?

Yours,

--
Barend Köbben
ITC - University of Twente,
Faculty of Geo-Information Science and Earth Observation
PO Box 217, 7500AE Enschede (The Netherlands)
+31-(0)53 4874 253






Faculty of Geo-Information Science and Earth Observation (ITC)
University of Twente
Chamber of Commerce: 501305360000

E-mail disclaimer
The information in this e-mail, including any attachments, is intended for the addressee only. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or action in relation to the content of this information is strictly prohibited. If you have received this e-mail by mistake, please delete the message and any attachment and inform the sender by return e-mail. ITC accepts no liability for any error or omission in the message content or for damage of any kind that may arise as a result of e-mail transmission.

[ psqlodbc-Bugs-1010500 ] UUID not being returned correctly

2012-03-26T09:02:26

Bugs item #1010500, was opened at 28/10/2008 15:09
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1010500&group_id=1000125

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Philip Warner (pjw)
Assigned to: Nobody (None)
Summary: UUID not being returned correctly

Initial Comment:

I have the following in a postgres 8.3 DB:

Create Table test(f uuid);
insert into test values('e964684f-87fe-49d9-9b87-137cc83165ea');

I have the following VB.Net 2005 code that connects to this DB (using either ANSI or UNICODE driver); full connection string below. I use a DataAdapter as follows:

  Dim c As New ODBC.ODBCConnection(My.Settings.ConnectionString)
  Dim DA As New Odbc.OdbcDataAdapter("select f::text, f from test", c)
  Dim Tbl As New DataTable
  DA.Fill(zTbl)

When I inspect the values, they differ:

  ?tbl.Rows(0).Item(0).ToString
  "e964684f-87fe-49d9-9b87-137cc83165ea"
  ?tbl.Rows(0).Item(1).ToString
  "00390065-0036-0034-3600-380034006600"

The original can be stored using the ODBC driver, it just seems to have trouble retrieving it.



Full connection string:

Driver={PostgreSQL ANSI};database=time_log;server=xxx.yyy.zzz.ttt;port=5433;uid=root;sslmode=allow;readonly=0;protocol=7.4-1;fakeoidindex=0;showoidcolumn=0;rowversioning=0;showsystemtables=0;fetch=100;socket=4096;unknownsizes=0;maxvarcharsize=255;maxlongvarcharsize=8190;debug=0;commlog=0;optimizer=0;ksqo=1;usedeclarefetch=0;textaslongvarchar=1;unknownsaslongvarchar=0;boolsaschar=0;parse=0;cancelasfreestmt=0;extrasystableprefixes=dd_;lfconversion=1;updatablecursors=0;disallowpremature=0;trueisminus1=1;bi=0;byteaaslongvarbinary=0;useserversideprepare=0;lowercaseidentifier=0;xaopt=1



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

Comment By: Nicolas Helleringer (nhe)
Date: 26/03/2012 11:02

Message:
I don't understand

The log is the Mylgog for the DSN UUIDTest created for the test.

I do not know what you mean by or how to "turn on per DSN Mylog option" sorry

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

Comment By: Hiroshi Inoue (hinoue)
Date: 24/03/2012 16:09

Message:
Please turn on per DSN Mylog option as well.

regards,
Hiroshi inoue

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

Comment By: Nicolas Helleringer (nhe)
Date: 23/03/2012 14:39

Message:
Here you are :

[5928-0.000]CC_connect: entering...
[5928-0.001]sslmode=disable
[5928-0.001]original_CC_connect: entering...
[5928-0.003]Driver Version='09.01.0100,201112290002' linking 1400 dynamic Multithread library
[5928-0.011]original_CC_connect: DSN = 'UUIDTest', server = 'X.X.X.X', port = '5432', database = 'UUIDTest', username = 'access', password='xxxxx'
[5928-0.013]connecting to the server socket...
[5928-0.015](0)(null) ERRNO=0
[5928-0.016]connection to the server socket succeeded.
[5928-0.017]!!! usrname=access server=X.X.X.X
[5928-0.017]startup client_encoding=UTF8
[5928-0.018]sizeof startup packet = 97
[5928-0.019]sent the authentication block successfully.
[5928-0.019]gonna do authentication
[5928-0.019]read -1, global_socket_buffersize=4096
[5928-0.019]Lasterror=10035
[5928-0.070]read 13, global_socket_buffersize=4096
[5928-0.070]auth got 'R'
[5928-0.070]areq = 5 salt=b576b1d400
[5928-0.071]in AUTH_REQ_MD5
[5928-0.071]read -1, global_socket_buffersize=4096
[5928-0.071]Lasterror=10035
[5928-0.097]read 324, global_socket_buffersize=4096
[5928-0.097]auth got 'R'
[5928-0.097]areq = 0 salt=0000000000
[5928-0.097]auth got 'S'
[5928-0.097]auth got 'S'
[5928-0.097]auth got 'S'
[5928-0.097]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]Got the PostgreSQL version string: '9.0.3'
[5928-0.098]Extracted PostgreSQL version number: '9.0'
[5928-0.100]auth got 'S'
[5928-0.100]auth got 'S'
[5928-0.100]standard_conforming_strings=off
[5928-0.101]auth got 'S'
[5928-0.101]auth got 'K'
[5928-0.101]auth got 'Z'
[5928-0.101]CC_send_settings: entering...
[5928-0.101]PGAPI_AllocStmt: entering...
[5928-0.102]**** PGAPI_AllocStmt: hdbc = 00000000001BC460, stmt = 00000000001BF820
[5928-0.102]CC_add_statement: self=00000000001BC460, stmt=00000000001BF820
[5928-0.102]PGAPI_FreeStmt: entering...hstmt=00000000001BF820, fOption=1
[5928-0.103]QResult: enter DESTRUCTOR
[5928-0.103]SC_init_Result(1bf820)[5928-0.103]SC_Destructor: self=00000000001BF820, self->result=0000000000000000, self->hdbc=00000000001BC460
[5928-0.104]APD_free_params:  ENTER, self=00000000001BF9C8
[5928-0.104]IPD_free_params:  ENTER, self=00000000001BFA38
[5928-0.104]PDATA_free_params:  ENTER, self=00000000001BFB00
[5928-0.105]SC_Destructor: EXIT
[5928-0.105]CC_lookup_lo: entering...
[5928-0.105]CC_send_query: conn=00000000001BC460, query='select oid, typbasetype from pg_type where typname = 'lo''
[5928-0.106]send_query: done sending query 63bytes flushed
[5928-0.107]in QR_Constructor
[5928-0.107]exit QR_Constructor
[5928-0.107]read -1, global_socket_buffersize=4096
[5928-0.107]Lasterror=10035
[5928-0.133]read 79, global_socket_buffersize=4096
[5928-0.133]send_query: got id = 'T'
[5928-0.133]QR_fetch_tuples: cursor = '', self->cursor=0000000000000000
[5928-0.134]num_fields = 2
[5928-0.134]READING ATTTYPMOD
[5928-0.134]CI_read_fields: fieldname='oid', adtid=26, adtsize=4, atttypmod=-1 (rel,att)=(1247,65534)
[5928-0.135]READING ATTTYPMOD
[5928-0.135]CI_read_fields: fieldname='typbasetype', adtid=26, adtsize=4, atttypmod=-1 (rel,att)=(1247,24)
[5928-0.135]QR_fetch_tuples: past CI_read_fields: num_fields = 2
[5928-0.136]MALLOC: tuple_size = 100, size = 3200
[5928-0.136]QR_next_tuple: inTuples = true, falling through: fcount = 0, fetch_number = 0
[5928-0.136]end of tuple list -- setting inUse to false: this = 00000000001BF820 SELECT 0
[5928-0.137]_QR_next_tuple: 'C' fetch_total = 0 & this_fetch = 0
[5928-0.137]QR_next_tuple: backend_rows < CACHE_SIZE: brows = 0, cache_size = 0
[5928-0.138]QR_next_tuple: reached eof now
[5928-0.138]_QR_next_tuple: 'C': DONE (fcount == 0)
[5928-0.138]send_query: got id = 'Z'
[5928-0.139]QResult: enter DESTRUCTOR
[5928-0.139]QResult: in QR_close_result
[5928-0.139]QResult: free memory in, fcount=0
[5928-0.139]QResult: free memory out
[5928-0.139]QResult: enter DESTRUCTOR
[5928-0.140]QResult: exit close_result
[5928-0.140]QResult: exit DESTRUCTOR
[5928-0.140]Got the large object oid: -999
[5928-0.140]CC_lookup_characterset: entering...
[5928-0.141]conn->unicode=1
[5928-0.141]CC_connect: returning...1


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

Comment By: Hiroshi Inoue (hinoue)
Date: 23/03/2012 00:48

Message:
Hi Nicolas,

I cannot reproduce the case with MS Access 2002.
Could you attach the Mylog output of your case?

regards,
Hiroshi Inoue


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

Comment By: Nicolas Helleringer (nhe)
Date: 20/03/2012 16:26

Message:
Done the same on a x86 32 bits host / Access / ODBC driver

Same results, GUID are not well transfered.

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

Comment By: Nicolas Helleringer (nhe)
Date: 20/03/2012 15:10

Message:
Same bug here with the x64 latest driver version (2011-12-30 version)

Context :
- From MS Access 2010 64 bits
- Replication number field GUID
- Export table to ODBC tool

With the unicode driver the tables are created correctly i-e fields are mapped to uuid fields (with ansi version they are mapped to bytea fields) but data in them is not ok.

Source is GUID like : {7AB02082-2242-4A65-A7E3-6B624BF4873E}

Transfered data is like :  00410037-0042-0030-3200-300038003200

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

Comment By: Philip Warner (pjw)
Date: 01/11/2008 13:14

Message:
Thanks for the quick response!

I tried the ASCII driver, and it worked, which is great!

How stable are the beta drivers? and/or any schedule for
releasing a production version?

Thanks again.



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

Comment By: Hiroshi Inoue (hinoue)
Date: 31/10/2008 23:04

Message:
Could you try the drivers on testing for 8.3.0300 dll at
 http://www.geocities.jp/inocchichichi/psqlodbc/index.html
?

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

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1010500&group_id=1000125

[ psqlodbc-Bugs-1010500 ] UUID not being returned correctly

2012-03-24T15:09:08

Bugs item #1010500, was opened at 2008-10-28 14:09
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1010500&group_id=1000125

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Philip Warner (pjw)
Assigned to: Nobody (None)
Summary: UUID not being returned correctly

Initial Comment:

I have the following in a postgres 8.3 DB:

Create Table test(f uuid);
insert into test values('e964684f-87fe-49d9-9b87-137cc83165ea');

I have the following VB.Net 2005 code that connects to this DB (using either ANSI or UNICODE driver); full connection string below. I use a DataAdapter as follows:

  Dim c As New ODBC.ODBCConnection(My.Settings.ConnectionString)
  Dim DA As New Odbc.OdbcDataAdapter("select f::text, f from test", c)
  Dim Tbl As New DataTable
  DA.Fill(zTbl)

When I inspect the values, they differ:

  ?tbl.Rows(0).Item(0).ToString
  "e964684f-87fe-49d9-9b87-137cc83165ea"
  ?tbl.Rows(0).Item(1).ToString
  "00390065-0036-0034-3600-380034006600"

The original can be stored using the ODBC driver, it just seems to have trouble retrieving it.



Full connection string:

Driver={PostgreSQL ANSI};database=time_log;server=xxx.yyy.zzz.ttt;port=5433;uid=root;sslmode=allow;readonly=0;protocol=7.4-1;fakeoidindex=0;showoidcolumn=0;rowversioning=0;showsystemtables=0;fetch=100;socket=4096;unknownsizes=0;maxvarcharsize=255;maxlongvarcharsize=8190;debug=0;commlog=0;optimizer=0;ksqo=1;usedeclarefetch=0;textaslongvarchar=1;unknownsaslongvarchar=0;boolsaschar=0;parse=0;cancelasfreestmt=0;extrasystableprefixes=dd_;lfconversion=1;updatablecursors=0;disallowpremature=0;trueisminus1=1;bi=0;byteaaslongvarbinary=0;useserversideprepare=0;lowercaseidentifier=0;xaopt=1



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

Date: 2012-03-24 15:09

Message:
Please turn on per DSN Mylog option as well.

regards,
Hiroshi inoue

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

Comment By: Nicolas Helleringer (nhe)
Date: 2012-03-23 13:39

Message:
Here you are :

[5928-0.000]CC_connect: entering...
[5928-0.001]sslmode=disable
[5928-0.001]original_CC_connect: entering...
[5928-0.003]Driver Version='09.01.0100,201112290002' linking 1400 dynamic Multithread library
[5928-0.011]original_CC_connect: DSN = 'UUIDTest', server = 'X.X.X.X', port = '5432', database = 'UUIDTest', username = 'access', password='xxxxx'
[5928-0.013]connecting to the server socket...
[5928-0.015](0)(null) ERRNO=0
[5928-0.016]connection to the server socket succeeded.
[5928-0.017]!!! usrname=access server=X.X.X.X
[5928-0.017]startup client_encoding=UTF8
[5928-0.018]sizeof startup packet = 97
[5928-0.019]sent the authentication block successfully.
[5928-0.019]gonna do authentication
[5928-0.019]read -1, global_socket_buffersize=4096
[5928-0.019]Lasterror=10035
[5928-0.070]read 13, global_socket_buffersize=4096
[5928-0.070]auth got 'R'
[5928-0.070]areq = 5 salt=b576b1d400
[5928-0.071]in AUTH_REQ_MD5
[5928-0.071]read -1, global_socket_buffersize=4096
[5928-0.071]Lasterror=10035
[5928-0.097]read 324, global_socket_buffersize=4096
[5928-0.097]auth got 'R'
[5928-0.097]areq = 0 salt=0000000000
[5928-0.097]auth got 'S'
[5928-0.097]auth got 'S'
[5928-0.097]auth got 'S'
[5928-0.097]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]Got the PostgreSQL version string: '9.0.3'
[5928-0.098]Extracted PostgreSQL version number: '9.0'
[5928-0.100]auth got 'S'
[5928-0.100]auth got 'S'
[5928-0.100]standard_conforming_strings=off
[5928-0.101]auth got 'S'
[5928-0.101]auth got 'K'
[5928-0.101]auth got 'Z'
[5928-0.101]CC_send_settings: entering...
[5928-0.101]PGAPI_AllocStmt: entering...
[5928-0.102]**** PGAPI_AllocStmt: hdbc = 00000000001BC460, stmt = 00000000001BF820
[5928-0.102]CC_add_statement: self=00000000001BC460, stmt=00000000001BF820
[5928-0.102]PGAPI_FreeStmt: entering...hstmt=00000000001BF820, fOption=1
[5928-0.103]QResult: enter DESTRUCTOR
[5928-0.103]SC_init_Result(1bf820)[5928-0.103]SC_Destructor: self=00000000001BF820, self->result=0000000000000000, self->hdbc=00000000001BC460
[5928-0.104]APD_free_params:  ENTER, self=00000000001BF9C8
[5928-0.104]IPD_free_params:  ENTER, self=00000000001BFA38
[5928-0.104]PDATA_free_params:  ENTER, self=00000000001BFB00
[5928-0.105]SC_Destructor: EXIT
[5928-0.105]CC_lookup_lo: entering...
[5928-0.105]CC_send_query: conn=00000000001BC460, query='select oid, typbasetype from pg_type where typname = 'lo''
[5928-0.106]send_query: done sending query 63bytes flushed
[5928-0.107]in QR_Constructor
[5928-0.107]exit QR_Constructor
[5928-0.107]read -1, global_socket_buffersize=4096
[5928-0.107]Lasterror=10035
[5928-0.133]read 79, global_socket_buffersize=4096
[5928-0.133]send_query: got id = 'T'
[5928-0.133]QR_fetch_tuples: cursor = '', self->cursor=0000000000000000
[5928-0.134]num_fields = 2
[5928-0.134]READING ATTTYPMOD
[5928-0.134]CI_read_fields: fieldname='oid', adtid=26, adtsize=4, atttypmod=-1 (rel,att)=(1247,65534)
[5928-0.135]READING ATTTYPMOD
[5928-0.135]CI_read_fields: fieldname='typbasetype', adtid=26, adtsize=4, atttypmod=-1 (rel,att)=(1247,24)
[5928-0.135]QR_fetch_tuples: past CI_read_fields: num_fields = 2
[5928-0.136]MALLOC: tuple_size = 100, size = 3200
[5928-0.136]QR_next_tuple: inTuples = true, falling through: fcount = 0, fetch_number = 0
[5928-0.136]end of tuple list -- setting inUse to false: this = 00000000001BF820 SELECT 0
[5928-0.137]_QR_next_tuple: 'C' fetch_total = 0 & this_fetch = 0
[5928-0.137]QR_next_tuple: backend_rows < CACHE_SIZE: brows = 0, cache_size = 0
[5928-0.138]QR_next_tuple: reached eof now
[5928-0.138]_QR_next_tuple: 'C': DONE (fcount == 0)
[5928-0.138]send_query: got id = 'Z'
[5928-0.139]QResult: enter DESTRUCTOR
[5928-0.139]QResult: in QR_close_result
[5928-0.139]QResult: free memory in, fcount=0
[5928-0.139]QResult: free memory out
[5928-0.139]QResult: enter DESTRUCTOR
[5928-0.140]QResult: exit close_result
[5928-0.140]QResult: exit DESTRUCTOR
[5928-0.140]Got the large object oid: -999
[5928-0.140]CC_lookup_characterset: entering...
[5928-0.141]conn->unicode=1
[5928-0.141]CC_connect: returning...1


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

Comment By: Hiroshi Inoue (hinoue)
Date: 2012-03-22 23:48

Message:
Hi Nicolas,

I cannot reproduce the case with MS Access 2002.
Could you attach the Mylog output of your case?

regards,
Hiroshi Inoue


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

Comment By: Nicolas Helleringer (nhe)
Date: 2012-03-20 15:26

Message:
Done the same on a x86 32 bits host / Access / ODBC driver

Same results, GUID are not well transfered.

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

Comment By: Nicolas Helleringer (nhe)
Date: 2012-03-20 14:10

Message:
Same bug here with the x64 latest driver version (2011-12-30 version)

Context :
- From MS Access 2010 64 bits
- Replication number field GUID
- Export table to ODBC tool

With the unicode driver the tables are created correctly i-e fields are mapped to uuid fields (with ansi version they are mapped to bytea fields) but data in them is not ok.

Source is GUID like : {7AB02082-2242-4A65-A7E3-6B624BF4873E}

Transfered data is like :  00410037-0042-0030-3200-300038003200

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

Comment By: Philip Warner (pjw)
Date: 2008-11-01 12:14

Message:
Thanks for the quick response!

I tried the ASCII driver, and it worked, which is great!

How stable are the beta drivers? and/or any schedule for
releasing a production version?

Thanks again.



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

Comment By: Hiroshi Inoue (hinoue)
Date: 2008-10-31 22:04

Message:
Could you try the drivers on testing for 8.3.0300 dll at
 http://www.geocities.jp/inocchichichi/psqlodbc/index.html
?

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

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1010500&group_id=1000125

[ psqlodbc-Bugs-1010500 ] UUID not being returned correctly

2012-03-23T13:39:36

Bugs item #1010500, was opened at 28/10/2008 15:09
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1010500&group_id=1000125

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Philip Warner (pjw)
Assigned to: Nobody (None)
Summary: UUID not being returned correctly

Initial Comment:

I have the following in a postgres 8.3 DB:

Create Table test(f uuid);
insert into test values('e964684f-87fe-49d9-9b87-137cc83165ea');

I have the following VB.Net 2005 code that connects to this DB (using either ANSI or UNICODE driver); full connection string below. I use a DataAdapter as follows:

  Dim c As New ODBC.ODBCConnection(My.Settings.ConnectionString)
  Dim DA As New Odbc.OdbcDataAdapter("select f::text, f from test", c)
  Dim Tbl As New DataTable
  DA.Fill(zTbl)

When I inspect the values, they differ:

  ?tbl.Rows(0).Item(0).ToString
  "e964684f-87fe-49d9-9b87-137cc83165ea"
  ?tbl.Rows(0).Item(1).ToString
  "00390065-0036-0034-3600-380034006600"

The original can be stored using the ODBC driver, it just seems to have trouble retrieving it.



Full connection string:

Driver={PostgreSQL ANSI};database=time_log;server=xxx.yyy.zzz.ttt;port=5433;uid=root;sslmode=allow;readonly=0;protocol=7.4-1;fakeoidindex=0;showoidcolumn=0;rowversioning=0;showsystemtables=0;fetch=100;socket=4096;unknownsizes=0;maxvarcharsize=255;maxlongvarcharsize=8190;debug=0;commlog=0;optimizer=0;ksqo=1;usedeclarefetch=0;textaslongvarchar=1;unknownsaslongvarchar=0;boolsaschar=0;parse=0;cancelasfreestmt=0;extrasystableprefixes=dd_;lfconversion=1;updatablecursors=0;disallowpremature=0;trueisminus1=1;bi=0;byteaaslongvarbinary=0;useserversideprepare=0;lowercaseidentifier=0;xaopt=1



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

Comment By: Nicolas Helleringer (nhe)
Date: 23/03/2012 14:39

Message:
Here you are :

[5928-0.000]CC_connect: entering...
[5928-0.001]sslmode=disable
[5928-0.001]original_CC_connect: entering...
[5928-0.003]Driver Version='09.01.0100,201112290002' linking 1400 dynamic Multithread library
[5928-0.011]original_CC_connect: DSN = 'UUIDTest', server = 'X.X.X.X', port = '5432', database = 'UUIDTest', username = 'access', password='xxxxx'
[5928-0.013]connecting to the server socket...
[5928-0.015](0)(null) ERRNO=0
[5928-0.016]connection to the server socket succeeded.
[5928-0.017]!!! usrname=access server=X.X.X.X
[5928-0.017]startup client_encoding=UTF8
[5928-0.018]sizeof startup packet = 97
[5928-0.019]sent the authentication block successfully.
[5928-0.019]gonna do authentication
[5928-0.019]read -1, global_socket_buffersize=4096
[5928-0.019]Lasterror=10035
[5928-0.070]read 13, global_socket_buffersize=4096
[5928-0.070]auth got 'R'
[5928-0.070]areq = 5 salt=b576b1d400
[5928-0.071]in AUTH_REQ_MD5
[5928-0.071]read -1, global_socket_buffersize=4096
[5928-0.071]Lasterror=10035
[5928-0.097]read 324, global_socket_buffersize=4096
[5928-0.097]auth got 'R'
[5928-0.097]areq = 0 salt=0000000000
[5928-0.097]auth got 'S'
[5928-0.097]auth got 'S'
[5928-0.097]auth got 'S'
[5928-0.097]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]auth got 'S'
[5928-0.098]Got the PostgreSQL version string: '9.0.3'
[5928-0.098]Extracted PostgreSQL version number: '9.0'
[5928-0.100]auth got 'S'
[5928-0.100]auth got 'S'
[5928-0.100]standard_conforming_strings=off
[5928-0.101]auth got 'S'
[5928-0.101]auth got 'K'
[5928-0.101]auth got 'Z'
[5928-0.101]CC_send_settings: entering...
[5928-0.101]PGAPI_AllocStmt: entering...
[5928-0.102]**** PGAPI_AllocStmt: hdbc = 00000000001BC460, stmt = 00000000001BF820
[5928-0.102]CC_add_statement: self=00000000001BC460, stmt=00000000001BF820
[5928-0.102]PGAPI_FreeStmt: entering...hstmt=00000000001BF820, fOption=1
[5928-0.103]QResult: enter DESTRUCTOR
[5928-0.103]SC_init_Result(1bf820)[5928-0.103]SC_Destructor: self=00000000001BF820, self->result=0000000000000000, self->hdbc=00000000001BC460
[5928-0.104]APD_free_params:  ENTER, self=00000000001BF9C8
[5928-0.104]IPD_free_params:  ENTER, self=00000000001BFA38
[5928-0.104]PDATA_free_params:  ENTER, self=00000000001BFB00
[5928-0.105]SC_Destructor: EXIT
[5928-0.105]CC_lookup_lo: entering...
[5928-0.105]CC_send_query: conn=00000000001BC460, query='select oid, typbasetype from pg_type where typname = 'lo''
[5928-0.106]send_query: done sending query 63bytes flushed
[5928-0.107]in QR_Constructor
[5928-0.107]exit QR_Constructor
[5928-0.107]read -1, global_socket_buffersize=4096
[5928-0.107]Lasterror=10035
[5928-0.133]read 79, global_socket_buffersize=4096
[5928-0.133]send_query: got id = 'T'
[5928-0.133]QR_fetch_tuples: cursor = '', self->cursor=0000000000000000
[5928-0.134]num_fields = 2
[5928-0.134]READING ATTTYPMOD
[5928-0.134]CI_read_fields: fieldname='oid', adtid=26, adtsize=4, atttypmod=-1 (rel,att)=(1247,65534)
[5928-0.135]READING ATTTYPMOD
[5928-0.135]CI_read_fields: fieldname='typbasetype', adtid=26, adtsize=4, atttypmod=-1 (rel,att)=(1247,24)
[5928-0.135]QR_fetch_tuples: past CI_read_fields: num_fields = 2
[5928-0.136]MALLOC: tuple_size = 100, size = 3200
[5928-0.136]QR_next_tuple: inTuples = true, falling through: fcount = 0, fetch_number = 0
[5928-0.136]end of tuple list -- setting inUse to false: this = 00000000001BF820 SELECT 0
[5928-0.137]_QR_next_tuple: 'C' fetch_total = 0 & this_fetch = 0
[5928-0.137]QR_next_tuple: backend_rows < CACHE_SIZE: brows = 0, cache_size = 0
[5928-0.138]QR_next_tuple: reached eof now
[5928-0.138]_QR_next_tuple: 'C': DONE (fcount == 0)
[5928-0.138]send_query: got id = 'Z'
[5928-0.139]QResult: enter DESTRUCTOR
[5928-0.139]QResult: in QR_close_result
[5928-0.139]QResult: free memory in, fcount=0
[5928-0.139]QResult: free memory out
[5928-0.139]QResult: enter DESTRUCTOR
[5928-0.140]QResult: exit close_result
[5928-0.140]QResult: exit DESTRUCTOR
[5928-0.140]Got the large object oid: -999
[5928-0.140]CC_lookup_characterset: entering...
[5928-0.141]conn->unicode=1
[5928-0.141]CC_connect: returning...1


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

Comment By: Hiroshi Inoue (hinoue)
Date: 23/03/2012 00:48

Message:
Hi Nicolas,

I cannot reproduce the case with MS Access 2002.
Could you attach the Mylog output of your case?

regards,
Hiroshi Inoue


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

Comment By: Nicolas Helleringer (nhe)
Date: 20/03/2012 16:26

Message:
Done the same on a x86 32 bits host / Access / ODBC driver

Same results, GUID are not well transfered.

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

Comment By: Nicolas Helleringer (nhe)
Date: 20/03/2012 15:10

Message:
Same bug here with the x64 latest driver version (2011-12-30 version)

Context :
- From MS Access 2010 64 bits
- Replication number field GUID
- Export table to ODBC tool

With the unicode driver the tables are created correctly i-e fields are mapped to uuid fields (with ansi version they are mapped to bytea fields) but data in them is not ok.

Source is GUID like : {7AB02082-2242-4A65-A7E3-6B624BF4873E}

Transfered data is like :  00410037-0042-0030-3200-300038003200

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

Comment By: Philip Warner (pjw)
Date: 01/11/2008 13:14

Message:
Thanks for the quick response!

I tried the ASCII driver, and it worked, which is great!

How stable are the beta drivers? and/or any schedule for
releasing a production version?

Thanks again.



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

Comment By: Hiroshi Inoue (hinoue)
Date: 31/10/2008 23:04

Message:
Could you try the drivers on testing for 8.3.0300 dll at
 http://www.geocities.jp/inocchichichi/psqlodbc/index.html
?

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

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1010500&group_id=1000125

[ psqlodbc-Bugs-1010500 ] UUID not being returned correctly

2012-03-22T23:48:43

Bugs item #1010500, was opened at 2008-10-28 14:09
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1010500&group_id=1000125

Category: None
Group: None
Resolution: None
Priority: 3
Submitted By: Philip Warner (pjw)
Assigned to: Nobody (None)
Summary: UUID not being returned correctly

Initial Comment:

I have the following in a postgres 8.3 DB:

Create Table test(f uuid);
insert into test values('e964684f-87fe-49d9-9b87-137cc83165ea');

I have the following VB.Net 2005 code that connects to this DB (using either ANSI or UNICODE driver); full connection string below. I use a DataAdapter as follows:

  Dim c As New ODBC.ODBCConnection(My.Settings.ConnectionString)
  Dim DA As New Odbc.OdbcDataAdapter("select f::text, f from test", c)
  Dim Tbl As New DataTable
  DA.Fill(zTbl)

When I inspect the values, they differ:

  ?tbl.Rows(0).Item(0).ToString
  "e964684f-87fe-49d9-9b87-137cc83165ea"
  ?tbl.Rows(0).Item(1).ToString
  "00390065-0036-0034-3600-380034006600"

The original can be stored using the ODBC driver, it just seems to have trouble retrieving it.



Full connection string:

Driver={PostgreSQL ANSI};database=time_log;server=xxx.yyy.zzz.ttt;port=5433;uid=root;sslmode=allow;readonly=0;protocol=7.4-1;fakeoidindex=0;showoidcolumn=0;rowversioning=0;showsystemtables=0;fetch=100;socket=4096;unknownsizes=0;maxvarcharsize=255;maxlongvarcharsize=8190;debug=0;commlog=0;optimizer=0;ksqo=1;usedeclarefetch=0;textaslongvarchar=1;unknownsaslongvarchar=0;boolsaschar=0;parse=0;cancelasfreestmt=0;extrasystableprefixes=dd_;lfconversion=1;updatablecursors=0;disallowpremature=0;trueisminus1=1;bi=0;byteaaslongvarbinary=0;useserversideprepare=0;lowercaseidentifier=0;xaopt=1



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

Date: 2012-03-22 23:48

Message:
Hi Nicolas,

I cannot reproduce the case with MS Access 2002.
Could you attach the Mylog output of your case?

regards,
Hiroshi Inoue


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

Comment By: Nicolas Helleringer (nhe)
Date: 2012-03-20 15:26

Message:
Done the same on a x86 32 bits host / Access / ODBC driver

Same results, GUID are not well transfered.

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

Comment By: Nicolas Helleringer (nhe)
Date: 2012-03-20 14:10

Message:
Same bug here with the x64 latest driver version (2011-12-30 version)

Context :
- From MS Access 2010 64 bits
- Replication number field GUID
- Export table to ODBC tool

With the unicode driver the tables are created correctly i-e fields are mapped to uuid fields (with ansi version they are mapped to bytea fields) but data in them is not ok.

Source is GUID like : {7AB02082-2242-4A65-A7E3-6B624BF4873E}

Transfered data is like :  00410037-0042-0030-3200-300038003200

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

Comment By: Philip Warner (pjw)
Date: 2008-11-01 12:14

Message:
Thanks for the quick response!

I tried the ASCII driver, and it worked, which is great!

How stable are the beta drivers? and/or any schedule for
releasing a production version?

Thanks again.



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

Comment By: Hiroshi Inoue (hinoue)
Date: 2008-10-31 22:04

Message:
Could you try the drivers on testing for 8.3.0300 dll at
 http://www.geocities.jp/inocchichichi/psqlodbc/index.html
?

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

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1010500&group_id=1000125

[ psqlodbc-Bugs-1010500 ] UUID not being returned correctly

2012-03-20T15:26:50

Bugs item #1010500, was opened at 28/10/2008 15:09
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1010500&group_id=1000125

Category: None
Group: None
Status: Closed
Resolution: None
Priority: 3
Submitted By: Philip Warner (pjw)
Assigned to: Nobody (None)
Summary: UUID not being returned correctly

Initial Comment:

I have the following in a postgres 8.3 DB:

Create Table test(f uuid);
insert into test values('e964684f-87fe-49d9-9b87-137cc83165ea');

I have the following VB.Net 2005 code that connects to this DB (using either ANSI or UNICODE driver); full connection string below. I use a DataAdapter as follows:

  Dim c As New ODBC.ODBCConnection(My.Settings.ConnectionString)
  Dim DA As New Odbc.OdbcDataAdapter("select f::text, f from test", c)
  Dim Tbl As New DataTable
  DA.Fill(zTbl)

When I inspect the values, they differ:

  ?tbl.Rows(0).Item(0).ToString
  "e964684f-87fe-49d9-9b87-137cc83165ea"
  ?tbl.Rows(0).Item(1).ToString
  "00390065-0036-0034-3600-380034006600"

The original can be stored using the ODBC driver, it just seems to have trouble retrieving it.



Full connection string:

Driver={PostgreSQL ANSI};database=time_log;server=xxx.yyy.zzz.ttt;port=5433;uid=root;sslmode=allow;readonly=0;protocol=7.4-1;fakeoidindex=0;showoidcolumn=0;rowversioning=0;showsystemtables=0;fetch=100;socket=4096;unknownsizes=0;maxvarcharsize=255;maxlongvarcharsize=8190;debug=0;commlog=0;optimizer=0;ksqo=1;usedeclarefetch=0;textaslongvarchar=1;unknownsaslongvarchar=0;boolsaschar=0;parse=0;cancelasfreestmt=0;extrasystableprefixes=dd_;lfconversion=1;updatablecursors=0;disallowpremature=0;trueisminus1=1;bi=0;byteaaslongvarbinary=0;useserversideprepare=0;lowercaseidentifier=0;xaopt=1



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

Comment By: Nicolas Helleringer (nhe)
Date: 20/03/2012 16:26

Message:
Done the same on a x86 32 bits host / Access / ODBC driver

Same results, GUID are not well transfered.

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

Comment By: Nicolas Helleringer (nhe)
Date: 20/03/2012 15:10

Message:
Same bug here with the x64 latest driver version (2011-12-30 version)

Context :
- From MS Access 2010 64 bits
- Replication number field GUID
- Export table to ODBC tool

With the unicode driver the tables are created correctly i-e fields are mapped to uuid fields (with ansi version they are mapped to bytea fields) but data in them is not ok.

Source is GUID like : {7AB02082-2242-4A65-A7E3-6B624BF4873E}

Transfered data is like :  00410037-0042-0030-3200-300038003200

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

Comment By: Philip Warner (pjw)
Date: 01/11/2008 13:14

Message:
Thanks for the quick response!

I tried the ASCII driver, and it worked, which is great!

How stable are the beta drivers? and/or any schedule for
releasing a production version?

Thanks again.



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

Comment By: Hiroshi Inoue (hinoue)
Date: 31/10/2008 23:04

Message:
Could you try the drivers on testing for 8.3.0300 dll at
 http://www.geocities.jp/inocchichichi/psqlodbc/index.html
?

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

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1010500&group_id=1000125

[ psqlodbc-Bugs-1010500 ] UUID not being returned correctly

2012-03-20T14:10:32

Bugs item #1010500, was opened at 28/10/2008 15:09
You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1010500&group_id=1000125

Category: None
Group: None
Status: Closed
Resolution: None
Priority: 3
Submitted By: Philip Warner (pjw)
Assigned to: Nobody (None)
Summary: UUID not being returned correctly

Initial Comment:

I have the following in a postgres 8.3 DB:

Create Table test(f uuid);
insert into test values('e964684f-87fe-49d9-9b87-137cc83165ea');

I have the following VB.Net 2005 code that connects to this DB (using either ANSI or UNICODE driver); full connection string below. I use a DataAdapter as follows:

  Dim c As New ODBC.ODBCConnection(My.Settings.ConnectionString)
  Dim DA As New Odbc.OdbcDataAdapter("select f::text, f from test", c)
  Dim Tbl As New DataTable
  DA.Fill(zTbl)

When I inspect the values, they differ:

  ?tbl.Rows(0).Item(0).ToString
  "e964684f-87fe-49d9-9b87-137cc83165ea"
  ?tbl.Rows(0).Item(1).ToString
  "00390065-0036-0034-3600-380034006600"

The original can be stored using the ODBC driver, it just seems to have trouble retrieving it.



Full connection string:

Driver={PostgreSQL ANSI};database=time_log;server=xxx.yyy.zzz.ttt;port=5433;uid=root;sslmode=allow;readonly=0;protocol=7.4-1;fakeoidindex=0;showoidcolumn=0;rowversioning=0;showsystemtables=0;fetch=100;socket=4096;unknownsizes=0;maxvarcharsize=255;maxlongvarcharsize=8190;debug=0;commlog=0;optimizer=0;ksqo=1;usedeclarefetch=0;textaslongvarchar=1;unknownsaslongvarchar=0;boolsaschar=0;parse=0;cancelasfreestmt=0;extrasystableprefixes=dd_;lfconversion=1;updatablecursors=0;disallowpremature=0;trueisminus1=1;bi=0;byteaaslongvarbinary=0;useserversideprepare=0;lowercaseidentifier=0;xaopt=1



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

Comment By: Nicolas Helleringer (nhe)
Date: 20/03/2012 15:10

Message:
Same bug here with the x64 latest driver version (2011-12-30 version)

Context :
- From MS Access 2010 64 bits
- Replication number field GUID
- Export table to ODBC tool

With the unicode driver the tables are created correctly i-e fields are mapped to uuid fields (with ansi version they are mapped to bytea fields) but data in them is not ok.

Source is GUID like : {7AB02082-2242-4A65-A7E3-6B624BF4873E}

Transfered data is like :  00410037-0042-0030-3200-300038003200

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

Comment By: Philip Warner (pjw)
Date: 01/11/2008 13:14

Message:
Thanks for the quick response!

I tried the ASCII driver, and it worked, which is great!

How stable are the beta drivers? and/or any schedule for
releasing a production version?

Thanks again.



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

Comment By: Hiroshi Inoue (hinoue)
Date: 31/10/2008 23:04

Message:
Could you try the drivers on testing for 8.3.0300 dll at
 http://www.geocities.jp/inocchichichi/psqlodbc/index.html
?

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

You can respond by visiting: 
http://pgfoundry.org/tracker/?func=detail&atid=538&aid=1010500&group_id=1000125