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