Обсуждение: Errors using psqlodbc

(2010/11/03 1:46), Nelson Andre wrote:
> Hi there ,
>
> I’m using psqlodbc version 9.00.01.01 UNICODE , in Windows Server 2003.
>
> Have created a new data source and activated the logs.
>
> In the psqlodbc logs I get the following error messages:
>
> [0.002]conn=026B40E0, PGAPI_DriverConnect( in)='DSN=PostgresTeste;',
> fDriverCompletion=1
>
> [0.011]DSN info:
> DSN='PostgresTeste',server='libra',port='5432',dbase='mtransteste',user='minimal',passwd='xxxxx'
>
> [0.021]
> onlyread='0',protocol='7.4',showoid='0',fakeoidindex='0',showsystable='0'
>
> [0.028] conn_settings='', conn_encoding='(null)'
>
> [0.032] translation_dll='',translation_option=''
>
> [0.053]Driver Version='09.00.0101,201010160001' linking 1500 static
> Multithread library
>
> [0.074]Global Options: fetch=100, socket=4096, unknown_sizes=0,
> max_varchar_size=255, max_longvarchar_size=8190
>
> [0.099] disable_optimizer=0, ksqo=1, unique_index=1, use_declarefetch=1
>
> [0.106] text_as_longvarchar=1, unknowns_as_longvarchar=0,
> bools_as_char=1 NAMEDATALEN=64
>
> [0.113] extra_systable_prefixes='dd_;', conn_settings='' conn_encoding=''
>
> [0.250] [ PostgreSQL version string = '8.4.4' ]
>
> [0.252] [ PostgreSQL version number = '8.4' ]
>
> [0.316]conn=026B40E0, query='select oid, typbasetype from pg_type where
> typname = 'lo''
>
> [0.377] [ fetched 0 rows ]
>
> [0.417] [ Large Object oid = -999 ]
>
> [0.422] [ Client encoding = 'UTF8' (code = 6) ]
>
> [0.443]conn=026B40E0,
>
PGAPI_DriverConnect(out)='DSN=PostgresTeste;DATABASE=mtransteste;SERVER=libra;PORT=5432;UID=minimal;PWD=xxxxxxx;CA=d;A6=;A7=100;A8=4096;B0=255;B1=8190;BI=0;C2=dd_;;CX=1c54ebb;A1=7.4-1'
>
> [6.044]CONN ERROR: func=set_statement_option, desc='', errnum=-1,
> errmsg='Requested value changed.'
>
> [6.057] ------------------------------------------------------------
>
> [6.062] henv=026B2150, conn=026B40E0, status=1, num_stmts=16
>
> [6.067] sock=026B2180, stmts=026B2250, lobj_type=-999
>
> [6.071] ---------------- Socket Info -------------------------------
>
> [6.075] socket=612, reverse=0, errornumber=0, errormsg='(NULL)'
>
> [6.080] buffer_in=40594504, buffer_out=40598608
>
> [6.083] buffer_filled_in=77, buffer_filled_out=0, buffer_read_in=77
>
> [6.090]CONN ERROR: func=PGAPI_SetConnectOption, desc='', errnum=-1,
> errmsg='Requested value changed.'
>
> [6.104] ------------------------------------------------------------
>
> [6.108] henv=026B2150, conn=026B40E0, status=1, num_stmts=16
>
> [6.112] sock=026B2180, stmts=026B2250, lobj_type=-999
>
> [6.115] ---------------- Socket Info -------------------------------
>
> [6.120] socket=612, reverse=0, errornumber=0, errormsg='(NULL)'
>
> [6.125] buffer_in=40594504, buffer_out=40598608
>
> [6.128] buffer_filled_in=77, buffer_filled_out=0, buffer_read_in=77
>
> [6.160]CONN ERROR: func=set_statement_option, desc='', errnum=-1,
> errmsg='Requested value changed.'
>
> [6.172] ------------------------------------------------------------
>
> [6.177] henv=026B2150, conn=026B40E0, status=1, num_stmts=16
>
> [6.181] sock=026B2180, stmts=026B2250, lobj_type=-999
>
> [6.186] ---------------- Socket Info -------------------------------
>
> [6.191] socket=612, reverse=0, errornumber=0, errormsg='(NULL)'
>
> [6.195] buffer_in=40594504, buffer_out=40598608
>
> [6.199] buffer_filled_in=77, buffer_filled_out=0, buffer_read_in=77
>
> [6.207]CONN ERROR: func=PGAPI_SetConnectOption, desc='', errnum=-1,
> errmsg='Requested value changed.'
>
> [6.218] ------------------------------------------------------------
>
> [6.222] henv=026B2150, conn=026B40E0, status=1, num_stmts=16
>
> [6.226] sock=026B2180, stmts=026B2250, lobj_type=-999
>
> [6.232] ---------------- Socket Info -------------------------------
>
> [6.237] socket=612, reverse=0, errornumber=0, errormsg='(NULL)'
>
> [6.242] buffer_in=40594504, buffer_out=40598608
>
> [6.246] buffer_filled_in=77, buffer_filled_out=0, buffer_read_in=77
>
> I get those 4 CONN ERROR and can’t find anything related to them
>
> Any help?

Those messages are warnings not errors.

regards,
Hiroshi Inoue

Hi all,

apologies if this is already in the bug tracker (I had a look but didn't
find it).

We recently did some work to get our product working with PostgreSQL 9.0
and the latest ODBC driver.  Our code is written to (try to) be
DBMS-agnostic.  So it enumerates reported types, searches for matching
types etc, and builds CREATE TABLE statements etc from what it finds.

There were a couple of inconsistencies in data returned from the ODBC
driver.

1. Data returned from SQLGetTypeInfo uses ODBC2 field names.

The columns reported include

"PRECISION" instead of "COLUMN_SIZE"
"MONEY" instead of "FIXED_PREC_SCALE"
"AUTO_INCREMENT" instead of "AUTO_UNIQUE_VALUE"

2. Data returned from SQLTables uses ODBC2 field names

"TABLE_QUALIFIER" instead of "TABLE_CAT"
"TABLE_OWNER" instead of "TABLE_SCHEM"

These 2 issues aren't huge problems, since the ordinal column number
stays the same.

3. Not all supported types returned by SQLGetTypeInfo

Specifically the types SERIAL and BIGSERIAL are not reported.  This
means we needed to hard-code a hack so if the driver was PostgreSQL and
we needed an AUTO_UNIQUE_VALUE counter, we used "SERIAL".  It works, but
if SQLGetTypeInfo returned these types, it wouldn't need the hack.

4.  Oddness with bigint fields.

bigint reported as precision of 19, instead of 20.  This isn't big
enough to store an unsigned __int64

5. Oddness with double precision fields.

We had to use double precision fields to store file size information,
because bigint couldn't do an __int64 (not sure what actual C type this
really maps to in reality).  However when we get the field data back in
a query, it is reported as type SQL_FLOAT, even though the DB structure
in the PostgreSQL manager shows it as double precision.  Obviously you
don't want to truncate double to float, so is this just in the driver
(some type switch case not supported?)

Once we worked around all these issues, it seems to be working great.
I'm a bit concerned about losing precision with double vs float though.

Regards

Adrien

Hi,

(2010/11/03 12:22), Adrien de Croy wrote:
>
> Hi all,
>
> apologies if this is already in the bug tracker (I had a look but didn't
> find it).
>
> We recently did some work to get our product working with PostgreSQL 9.0
> and the latest ODBC driver. Our code is written to (try to) be
> DBMS-agnostic. So it enumerates reported types, searches for matching
> types etc, and builds CREATE TABLE statements etc from what it finds.
>
> There were a couple of inconsistencies in data returned from the ODBC
> driver.
>
> 1. Data returned from SQLGetTypeInfo uses ODBC2 field names.
>
> The columns reported include
>
> "PRECISION" instead of "COLUMN_SIZE"
> "MONEY" instead of "FIXED_PREC_SCALE"
> "AUTO_INCREMENT" instead of "AUTO_UNIQUE_VALUE"
>
> 2. Data returned from SQLTables uses ODBC2 field names
>
> "TABLE_QUALIFIER" instead of "TABLE_CAT"
> "TABLE_OWNER" instead of "TABLE_SCHEM"
>
> These 2 issues aren't huge problems, since the ordinal column number
> stays the same.
>
> 3. Not all supported types returned by SQLGetTypeInfo
>
> Specifically the types SERIAL and BIGSERIAL are not reported. This means
> we needed to hard-code a hack so if the driver was PostgreSQL and we
> needed an AUTO_UNIQUE_VALUE counter, we used "SERIAL". It works, but if
> SQLGetTypeInfo returned these types, it wouldn't need the hack.
>
> 4. Oddness with bigint fields.
>
> bigint reported as precision of 19, instead of 20. This isn't big enough
> to store an unsigned __int64

Because int8 type in PostgreSQL is signed, the precision is 19.

> 5. Oddness with double precision fields.
>
> We had to use double precision fields to store file size information,
> because bigint couldn't do an __int64 (not sure what actual C type this
> really maps to in reality). However when we get the field data back in a
> query, it is reported as type SQL_FLOAT, even though the DB structure in
> the PostgreSQL manager shows it as double precision. Obviously you don't
> want to truncate double to float, so is this just in the driver (some
> type switch case not supported?)

SQL_FLOAT means double precision type. What means signle precision type
is SQL_REAL.

> Once we worked around all these issues, it seems to be working great.
> I'm a bit concerned about losing precision with double vs float though.
>
> Regards
>
> Adrien

  Hi

On 3/11/2010 9:36 p.m., Hiroshi Inoue wrote:
> Hi,
>
> (2010/11/03 12:22), Adrien de Croy wrote: 5. Oddness with double
> precision fields.
>>
>> We had to use double precision fields to store file size information,
>> because bigint couldn't do an __int64 (not sure what actual C type this
>> really maps to in reality). However when we get the field data back in a
>> query, it is reported as type SQL_FLOAT, even though the DB structure in
>> the PostgreSQL manager shows it as double precision. Obviously you don't
>> want to truncate double to float, so is this just in the driver (some
>> type switch case not supported?)
>
> SQL_FLOAT means double precision type. What means signle precision type
> is SQL_REAL.

When I tried to store a C double type (8byte floating point) into this
field which reported itself as SQL_FLOAT even though it's "double
precision", it reported that the thing I was poking in was too big, so I
had to fall back to storing it as a C float type.  This is using
SQLBindParameter.

my understanding is SQL_DOUBLE is required.   Is that used?  It's
certainly used by other DBs, such as MySQL, MS SQL server and Access even.

Thanks for your reply

Regards

Adrien

>
>> Once we worked around all these issues, it seems to be working great.
>> I'm a bit concerned about losing precision with double vs float though.
>>
>> Regards
>>
>> Adrien
>

--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Hi again

apologies, I did some more research.  Looks like SQL_FLOAT and
SQL_DOUBLE are used for c double types, and SQL_REAL for c float type.

very confusing, but that's not unusual for ODBC.

So I've also managed to solve my bigint issue, by falling back to a
signed __int64 instead of unsigned.  I guess there's no plan to
implement unsigned numeric types?

Adrien


On 3/11/2010 9:36 p.m., Hiroshi Inoue wrote:
> Hi,
>
> (2010/11/03 12:22), Adrien de Croy wrote:
>>
>> Hi all,
>>
>> apologies if this is already in the bug tracker (I had a look but didn't
>> find it).
>>
>> We recently did some work to get our product working with PostgreSQL 9.0
>> and the latest ODBC driver. Our code is written to (try to) be
>> DBMS-agnostic. So it enumerates reported types, searches for matching
>> types etc, and builds CREATE TABLE statements etc from what it finds.
>>
>> There were a couple of inconsistencies in data returned from the ODBC
>> driver.
>>
>> 1. Data returned from SQLGetTypeInfo uses ODBC2 field names.
>>
>> The columns reported include
>>
>> "PRECISION" instead of "COLUMN_SIZE"
>> "MONEY" instead of "FIXED_PREC_SCALE"
>> "AUTO_INCREMENT" instead of "AUTO_UNIQUE_VALUE"
>>
>> 2. Data returned from SQLTables uses ODBC2 field names
>>
>> "TABLE_QUALIFIER" instead of "TABLE_CAT"
>> "TABLE_OWNER" instead of "TABLE_SCHEM"
>>
>> These 2 issues aren't huge problems, since the ordinal column number
>> stays the same.
>>
>> 3. Not all supported types returned by SQLGetTypeInfo
>>
>> Specifically the types SERIAL and BIGSERIAL are not reported. This means
>> we needed to hard-code a hack so if the driver was PostgreSQL and we
>> needed an AUTO_UNIQUE_VALUE counter, we used "SERIAL". It works, but if
>> SQLGetTypeInfo returned these types, it wouldn't need the hack.
>>
>> 4. Oddness with bigint fields.
>>
>> bigint reported as precision of 19, instead of 20. This isn't big enough
>> to store an unsigned __int64
>
> Because int8 type in PostgreSQL is signed, the precision is 19.
>
>> 5. Oddness with double precision fields.
>>
>> We had to use double precision fields to store file size information,
>> because bigint couldn't do an __int64 (not sure what actual C type this
>> really maps to in reality). However when we get the field data back in a
>> query, it is reported as type SQL_FLOAT, even though the DB structure in
>> the PostgreSQL manager shows it as double precision. Obviously you don't
>> want to truncate double to float, so is this just in the driver (some
>> type switch case not supported?)
>
> SQL_FLOAT means double precision type. What means signle precision type
> is SQL_REAL.
>
>> Once we worked around all these issues, it seems to be working great.
>> I'm a bit concerned about losing precision with double vs float though.
>>
>> Regards
>>
>> Adrien
>
>

Hi Hiroshi,

The log keeps repeting some part of the text until I kill the application because it hangs and consumes 90+ % of the
CPU.
I will try the drivers you referred and then let you know.

Thanks.

Os melhores cumprimentos,
Nelson André
Senior Software Engineer
Maeil Consultores - Tecnologias de Integração de Empresas, Lda.
P: (+351) 214 229 117 F: (+351) 214 229 119
http://www.maeil.pt    http://helpdesk.maeil.pt


-----Original Message-----
From: Hiroshi Inoue [mailto:inoue@tpf.co.jp]
Sent: quinta-feira, 4 de Novembro de 2010 08:37
To: Nelson Andre
Cc: pgsql-odbc@postgresql.org
Subject: Re: [ODBC] Errors using psqlodbc

Hi Nelson,

(2010/11/03 19:05), Nelson Andre wrote:
> When I run my application , it hangs and I have to kill it in Task Manager.
>
> This is the content of mylog_5856.txt

.
.
> [5860-7.715]unquoted=1, quote=0, dquote=0, numeric=0, delim=' ', token='(', ptr='PGcA = ? ) ORDER BY PGcA '
> [5860-7.723]blevel++ ->  1
> [5860-7.724]unquoted=1, quote=0, dquote=0, numeric=0, delim=' ', token='PGcA', ptr='= ? ) ORDER BY PGcA '
> [5860-7.731]got ispunct: s[0] = '='
> [5860-7.733]unquoted=1, quote=0, dquote=0, numeric=0, delim=' ', token='=', ptr='? ) ORDER BY PGcA '
> [5860-7.740]got ispunct: s[0] = '?'
> [5860-7.744]unquoted=1, quote=0, dquote=0, numeric=0, delim=' ', token='?', ptr=') ORDER BY PGcA '
> [5860-7.752]got ispunct: s[0] = ')'
> [5860-7.753]unquoted=1, quote=0, dquote=0, numeric=0, delim=' ', token=')', ptr='ORDER BY PGcA '
> [5860-7.760]blevel-- = 0
> [5860-7.762]unquoted=1, quote=0, dquote=0, numeric=0, delim=' ', token='ORDER', ptr='BY PGcA '
> [5860-7.767]ORDER...
> [5860-7.769]unquoted=1, quote=0, dquote=0, numeric=0, delim=' ', token='BY', ptr='PGcA '
> [5860-7.774]unquoted=1, quote=0, dquote=0, numeric=0, delim='

Does the log stop here?
If so, could you please try the drivers on testing for 9.0.0201 at
   http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/
?

regards,
Hiroshi Inoue

Hi all

I'm getting an access violation from within SQLDescribeColW when I'm
getting the result scheme from a query.

the query is pretty simple:

SELECT count(*) as folder_files, sum(file_size) as folder_size,
sum(disk_use) as folder_size_disk, folder_id from cache_index where
volume_id = %u group by folder_id

SQLExecute returns OK
SQLNumResultCols returns 4 columns as expected

the SQLDescribeColW blows up when calling with column #2, corresponding
to sum(file_size).  file_size is a bigint field.  There are only 5
records, and the sum of the file_size is under 1MB.  So shouldn't be any
bigint overflow or something.

I used to use a double precision and it worked fine, then I figured out
how to store into a bigint field and now this happens every time I do
this query if there are any records in the table.  If there are no
records it's fine.

Regards

Adrien de Croy

Hi、

(2010/11/05 7:44), Adrien de Croy wrote:
>
> Hi all
>
> I'm getting an access violation from within SQLDescribeColW when I'm
> getting the result scheme from a query.

Hmm I may have introduced a bug in 9.0.0200.

Could you please try the drivers on testing for 9.0.0201 at
    http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/
?

regards,
Hiroshi Inoue

> the query is pretty simple:
>
> SELECT count(*) as folder_files, sum(file_size) as folder_size,
> sum(disk_use) as folder_size_disk, folder_id from cache_index where
> volume_id = %u group by folder_id
>
> SQLExecute returns OK
> SQLNumResultCols returns 4 columns as expected
>
> the SQLDescribeColW blows up when calling with column #2, corresponding
> to sum(file_size). file_size is a bigint field. There are only 5
> records, and the sum of the file_size is under 1MB. So shouldn't be any
> bigint overflow or something.
>
> I used to use a double precision and it worked fine, then I figured out
> how to store into a bigint field and now this happens every time I do
> this query if there are any records in the table. If there are no
> records it's fine.
>
> Regards
>
> Adrien de Croy

Hi Hiroshi

this build has another problem

::SQLTables no longer returns the table name at all (empty string).

So I can't test any further, since I require this for all my startup
code, type retrieval etc (for a column of a table def).

Regards

Adrien


On 5/11/2010 9:53 p.m., Hiroshi Inoue wrote:
> Hi、
>
> (2010/11/05 7:44), Adrien de Croy wrote:
>>
>> Hi all
>>
>> I'm getting an access violation from within SQLDescribeColW when I'm
>> getting the result scheme from a query.
>
> Hmm I may have introduced a bug in 9.0.0200.
>
> Could you please try the drivers on testing for 9.0.0201 at
>    http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/
> ?
>
> regards,
> Hiroshi Inoue
>
>> the query is pretty simple:
>>
>> SELECT count(*) as folder_files, sum(file_size) as folder_size,
>> sum(disk_use) as folder_size_disk, folder_id from cache_index where
>> volume_id = %u group by folder_id
>>
>> SQLExecute returns OK
>> SQLNumResultCols returns 4 columns as expected
>>
>> the SQLDescribeColW blows up when calling with column #2, corresponding
>> to sum(file_size). file_size is a bigint field. There are only 5
>> records, and the sum of the file_size is under 1MB. So shouldn't be any
>> bigint overflow or something.
>>
>> I used to use a double precision and it worked fine, then I figured out
>> how to store into a bigint field and now this happens every time I do
>> this query if there are any records in the table. If there are no
>> records it's fine.
>>
>> Regards
>>
>> Adrien de Croy
>
>

also seems to break the table scheme.  This one isn't important to me,
but maybe to others.

One other thing I found, even on the 9.00.0200 build.

Once you fetch data on a field in a record, if you try to fetch the same
field on the same row again (without moving cursor or anything) it blows
up also.  fetching seems to alter what you fetch.

Regards

Adrien


On 5/11/2010 9:53 p.m., Hiroshi Inoue wrote:
> Hi、
>
> (2010/11/05 7:44), Adrien de Croy wrote:
>>
>> Hi all
>>
>> I'm getting an access violation from within SQLDescribeColW when I'm
>> getting the result scheme from a query.
>
> Hmm I may have introduced a bug in 9.0.0200.
>
> Could you please try the drivers on testing for 9.0.0201 at
>    http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/
> ?
>
> regards,
> Hiroshi Inoue
>
>> the query is pretty simple:
>>
>> SELECT count(*) as folder_files, sum(file_size) as folder_size,
>> sum(disk_use) as folder_size_disk, folder_id from cache_index where
>> volume_id = %u group by folder_id
>>
>> SQLExecute returns OK
>> SQLNumResultCols returns 4 columns as expected
>>
>> the SQLDescribeColW blows up when calling with column #2, corresponding
>> to sum(file_size). file_size is a bigint field. There are only 5
>> records, and the sum of the file_size is under 1MB. So shouldn't be any
>> bigint overflow or something.
>>
>> I used to use a double precision and it worked fine, then I figured out
>> how to store into a bigint field and now this happens every time I do
>> this query if there are any records in the table. If there are no
>> records it's fine.
>>
>> Regards
>>
>> Adrien de Croy
>
>

(2010/11/10 10:40), Adrien de Croy wrote:
>
> Hi Hiroshi
>
> this build has another problem
>
> ::SQLTables no longer returns the table name at all (empty string).

Oops, I seem to have introduced another bug so as to fix
  [ODBC] Errors using psqlodbc .
I would fix it and report soon.

regards,
Hiroshi Inoue

> So I can't test any further, since I require this for all my startup
> code, type retrieval etc (for a column of a table def).
>
> Regards
>
> Adrien
>
>
> On 5/11/2010 9:53 p.m., Hiroshi Inoue wrote:
>> Hi、
>>
>> (2010/11/05 7:44), Adrien de Croy wrote:
>>>
>>> Hi all
>>>
>>> I'm getting an access violation from within SQLDescribeColW when I'm
>>> getting the result scheme from a query.
>>
>> Hmm I may have introduced a bug in 9.0.0200.
>>
>> Could you please try the drivers on testing for 9.0.0201 at
>> http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/
>> ?
>>
>> regards,
>> Hiroshi Inoue
>>
>>> the query is pretty simple:
>>>
>>> SELECT count(*) as folder_files, sum(file_size) as folder_size,
>>> sum(disk_use) as folder_size_disk, folder_id from cache_index where
>>> volume_id = %u group by folder_id
>>>
>>> SQLExecute returns OK
>>> SQLNumResultCols returns 4 columns as expected
>>>
>>> the SQLDescribeColW blows up when calling with column #2, corresponding
>>> to sum(file_size). file_size is a bigint field. There are only 5
>>> records, and the sum of the file_size is under 1MB. So shouldn't be any
>>> bigint overflow or something.
>>>
>>> I used to use a double precision and it worked fine, then I figured out
>>> how to store into a bigint field and now this happens every time I do
>>> this query if there are any records in the table. If there are no
>>> records it's fine.
>>>
>>> Regards
>>>
>>> Adrien de Croy

Hi Adrien,

(2010/11/10 10:48), Adrien de Croy wrote:
>
> also seems to break the table scheme. This one isn't important to me,
> but maybe to others.
>
> One other thing I found, even on the 9.00.0200 build.
>
> Once you fetch data on a field in a record, if you try to fetch the same
> field on the same row again (without moving cursor or anything) it blows
> up also. fetching seems to alter what you fetch.

What do you mean by *fetch(again)*?

regards,
Hiroshi Inoue

>
> On 5/11/2010 9:53 p.m., Hiroshi Inoue wrote:
>> Hi、
>>
>> (2010/11/05 7:44), Adrien de Croy wrote:
>>>
>>> Hi all
>>>
>>> I'm getting an access violation from within SQLDescribeColW when I'm
>>> getting the result scheme from a query.
>>
>> Hmm I may have introduced a bug in 9.0.0200.
>>
>> Could you please try the drivers on testing for 9.0.0201 at
>> http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/
>> ?
>>
>> regards,
>> Hiroshi Inoue
>>
>>> the query is pretty simple:
>>>
>>> SELECT count(*) as folder_files, sum(file_size) as folder_size,
>>> sum(disk_use) as folder_size_disk, folder_id from cache_index where
>>> volume_id = %u group by folder_id
>>>
>>> SQLExecute returns OK
>>> SQLNumResultCols returns 4 columns as expected
>>>
>>> the SQLDescribeColW blows up when calling with column #2, corresponding
>>> to sum(file_size). file_size is a bigint field. There are only 5
>>> records, and the sum of the file_size is under 1MB. So shouldn't be any
>>> bigint overflow or something.
>>>
>>> I used to use a double precision and it worked fine, then I figured out
>>> how to store into a bigint field and now this happens every time I do
>>> this query if there are any records in the table. If there are no
>>> records it's fine.
>>>
>>> Regards
>>>
>>> Adrien de Croy
>>
>>
>
>
>
>

Hi

I have some helper classes to fetch fields from a record, a helper class
to manage iteration through a result set.

If I call my fetch helper function for some field ordinal it works fine
the first time.  If I call it again (without having called any method to
change the current row in the result set) it fails on the same ordinal,
but works on other ordinals.

So, it looks to me like the fetch call is cleaning up the field data
when you fetch, rather than cleaning up the row when you say move to the
next row.

I don't know if this is a bug or not - for instance MS SQL server fails
if you fetch columns in a non-monitonically-increasing column ordinal
order.  E.g. fetch columns 1, 2, 3 works but not 1, 3, 2.  So maybe ODBC
doesn't guarantee it's safe to call fetch columns 1, 1, x

Adrien




On 10/11/2010 4:52 p.m., Hiroshi Inoue wrote:
> Hi Adrien,
>
> (2010/11/10 10:48), Adrien de Croy wrote:
>>
>> also seems to break the table scheme. This one isn't important to me,
>> but maybe to others.
>>
>> One other thing I found, even on the 9.00.0200 build.
>>
>> Once you fetch data on a field in a record, if you try to fetch the same
>> field on the same row again (without moving cursor or anything) it blows
>> up also. fetching seems to alter what you fetch.
>
> What do you mean by *fetch(again)*?
>
> regards,
> Hiroshi Inoue
>
>>
>> On 5/11/2010 9:53 p.m., Hiroshi Inoue wrote:
>>> Hi、
>>>
>>> (2010/11/05 7:44), Adrien de Croy wrote:
>>>>
>>>> Hi all
>>>>
>>>> I'm getting an access violation from within SQLDescribeColW when I'm
>>>> getting the result scheme from a query.
>>>
>>> Hmm I may have introduced a bug in 9.0.0200.
>>>
>>> Could you please try the drivers on testing for 9.0.0201 at
>>> http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/
>>> ?
>>>
>>> regards,
>>> Hiroshi Inoue
>>>
>>>> the query is pretty simple:
>>>>
>>>> SELECT count(*) as folder_files, sum(file_size) as folder_size,
>>>> sum(disk_use) as folder_size_disk, folder_id from cache_index where
>>>> volume_id = %u group by folder_id
>>>>
>>>> SQLExecute returns OK
>>>> SQLNumResultCols returns 4 columns as expected
>>>>
>>>> the SQLDescribeColW blows up when calling with column #2,
>>>> corresponding
>>>> to sum(file_size). file_size is a bigint field. There are only 5
>>>> records, and the sum of the file_size is under 1MB. So shouldn't be
>>>> any
>>>> bigint overflow or something.
>>>>
>>>> I used to use a double precision and it worked fine, then I figured
>>>> out
>>>> how to store into a bigint field and now this happens every time I do
>>>> this query if there are any records in the table. If there are no
>>>> records it's fine.
>>>>
>>>> Regards
>>>>
>>>> Adrien de Croy
>>>
>>>
>>
>>
>>
>>
>
>

(2010/11/10 13:04), Adrien de Croy wrote:
>
> Hi
>
> I have some helper classes to fetch fields from a record, a helper class
> to manage iteration through a result set.
>
> If I call my fetch helper function for some field ordinal it works fine
> the first time. If I call it again (without having called any method to
> change the current row in the result set) it fails on the same ordinal,
> but works on other ordinals.
>
> So, it looks to me like the fetch call is cleaning up the field data
> when you fetch,

If the helper function calls SQLGetData() for the column, yes.
SQLGetData() cleans up data which it returns to the caller and
returns SQL_NO_DATA when all data was returned to the caller.
You can divide into multiple SQLGetData() calls using this feature
when a column has a big data.

regards,
Hiroshi Inoue