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

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
>>>
>>>
>>
>>
>>
>>
>
>