Re: Access violation (0xC0000005) in PSQLODBC35W.DLL when calling SQLDescribeColW
От | Hiroshi Inoue |
---|---|
Тема | Re: Access violation (0xC0000005) in PSQLODBC35W.DLL when calling SQLDescribeColW |
Дата | |
Msg-id | 4CD3C5F1.80606@tpf.co.jp обсуждение исходный текст |
Ответ на | Access violation (0xC0000005) in PSQLODBC35W.DLL when calling SQLDescribeColW (Adrien de Croy <adrien@qbik.com>) |
Ответы |
Re: Access violation (0xC0000005) in PSQLODBC35W.DLL when
calling SQLDescribeColW
Re: Access violation (0xC0000005) in PSQLODBC35W.DLL when calling SQLDescribeColW |
Список | pgsql-odbc |
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
В списке pgsql-odbc по дате отправления: