Обсуждение: Errors using psqlodbc
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?
Os melhores cumprimentos,
Nelson André
Senior Software Engineer
Maeil Consultores - Tecnologias de Integração de Empresas, Lda.
http://www.maeil.pt http://helpdesk.maeil.pt
AVISO DE CONFIDENCIALIDADE
Esta mensagem de correio electrónico e qualquer dos seus ficheiros anexos, caso existam, são confidenciais e destinados apenas à(s) pessoa(s) ou entidade(s) acima referida(s), podendo conter informação confidencial, privilegiada, a qual não deverá ser divulgada, copiada, gravada ou distribuída nos termos da lei vigente. Se não é o destinatário da mensagem, ou se ela lhe foi enviada por engano, agradecemos que não faça uso ou divulgação da mesma. A distribuição ou utilização da informação nela contida é VEDADA. Se recebeu esta mensagem por engano, por favor avise-nos de imediato, por correio electrónico, para o endereço acima e apague este e-mail do seu sistema. Obrigado.
CONFIDENTIALITY NOTICE
This e-mail transmission and eventual attached files are intended only for the use of the individual or entity named above and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in this transmission is strictly VOIDED. If you have received this transmission in error, please immediately notify us by e-mail at the above address and delete this e-mail from your system. Thank you.
(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
Various errors in psqlodbc: SQLGetTypeInfo, SQLTables, bigint, and double vs float
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
Re: Various errors in psqlodbc: SQLGetTypeInfo, SQLTables, bigint, and double vs float
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
Re: Various errors in psqlodbc: SQLGetTypeInfo, SQLTables, bigint, and double vs float
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
Re: Various errors in psqlodbc: SQLGetTypeInfo, SQLTables, bigint, and double vs float
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
Access violation (0xC0000005) in PSQLODBC35W.DLL when calling SQLDescribeColW
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
Re: Access violation (0xC0000005) in PSQLODBC35W.DLL when calling SQLDescribeColW
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
Re: Access violation (0xC0000005) in PSQLODBC35W.DLL when calling SQLDescribeColW
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 > >
Re: Access violation (0xC0000005) in PSQLODBC35W.DLL when calling SQLDescribeColW
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 > >
Re: Access violation (0xC0000005) in PSQLODBC35W.DLL when calling SQLDescribeColW
(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
Re: Access violation (0xC0000005) in PSQLODBC35W.DLL when calling SQLDescribeColW
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 >> >> > > > >
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 >>> >>> >> >> >> >> > >
Re: Access violation (0xC0000005) in PSQLODBC35W.DLL when calling SQLDescribeColW
(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