Skip site navigation (1) Skip section navigation (2)

Re: Access violation (0xC0000005) in PSQLODBC35W.DLL when calling SQLDescribeColW

From: Adrien de Croy <adrien(at)qbik(dot)com>
To: Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp>
Cc: "pgsql-odbc(at)postgresql(dot)org" <pgsql-odbc(at)postgresql(dot)org>
Subject: Re: Access violation (0xC0000005) in PSQLODBC35W.DLL when calling SQLDescribeColW
Date: 2010-11-10 04:04:21
Message-ID: 4CDA19C5.8070607@qbik.com (view raw or flat)
Thread:
Lists: pgsql-odbc
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
>>>
>>>
>>
>>
>>
>>
>
>

In response to

Responses

pgsql-odbc by date

Next:From: Hiroshi InoueDate: 2010-11-10 04:25:06
Subject: Re: Access violation (0xC0000005) in PSQLODBC35W.DLL when calling SQLDescribeColW
Previous:From: Hiroshi InoueDate: 2010-11-10 03:52:23
Subject: Re: Access violation (0xC0000005) in PSQLODBC35W.DLL when calling SQLDescribeColW

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group