Thread: New libpq based driver snapshot 08.01.0003 available
I've uploaded a new snapshot of the libpq based version of psqlODBC to ftp://ftp.postgresql.org/pub/odbc/versions/snapshots/.It will propagate onto the mirrors and the file listing on the websitewithin the next day or so. Important changes in this release include: - SSL support - Fixed a nasty SQLGetData/SQL_C_WCHAR bug that basically completely broke piecemeal retrieval of Unicode strings. This isbelieved to be /the/ bug that stopped many users using versions newer than 07.03.0200. - Fixed a bug new to the libpq version of the driver that prevented ODBCbench running properly in multithread transactionalmode, and completely broke Use Declare/Fetch mode. Please take some time to test this driver and report any bugs to pgsql-odbc@postgresql.org. Regards, Dave. Change list ----------- - Added SSL support - Fix some errors found by static source analysis (using Klocwork). [Tomas Skäre] - In SC_pos_reload_needed:2189 rows_per_fetch is uninitialised, if create_from_scratch is false, per Tomas Skäre - In SQLGetDescFieldW:128 blen is not initialised before sent to utf8_to_ucs2(). The same thing exists in SQLColAttributeW:287and SQLGetDiagFieldW:345, per Tomas Skäre - Get proper error messages from the server, rather than just saying the database doesn't exist. - Japanese GUI update from Hiroshi Saito - Include win_unicode.c in Unix build because it contains functions that are used under unix. - Fix SQL_MAX_IDENTIFIER_LEN per gborg bug ref: 1348 - Fix memory leak per gborg bug 1356 [pauldaugherty] - Fix unicode copy & convert bug. SQLGetData with SQL_C_WCHAR now returns SQL_SUCCESS once the whole string is sent, anddoesn't lose odd characters like it did. - Fix bug that stopped Use Declare/Fetch working, and prevented ODBC bench running in multi-thread, multi-transaction mode. - Add comment about a known leak bug that needs fixing - Handle SQL_DATE from ODBC2 apps, per bug report 1292 [ alic <NOSPAM> sokrates.hr] - Fix per bug ref 1187 [Scot Loach]
Dave Page írta:
> I've uploaded a new snapshot of the libpq based version of psqlODBC to
ftp://ftp.postgresql.org/pub/odbc/versions/snapshots/.It will propagate onto the mirrors and the file listing on the
websitewithin the next day or so.
>
> Important changes in this release include:
>
> - SSL support
>
> - Fixed a nasty SQLGetData/SQL_C_WCHAR bug that basically completely broke piecemeal retrieval of Unicode strings.
Thisis believed to be /the/ bug that stopped many users using versions newer than 07.03.0200.
>
> - Fixed a bug new to the libpq version of the driver that prevented ODBCbench running properly in multithread
transactionalmode, and completely broke Use Declare/Fetch mode.
>
> Please take some time to test this driver and report any bugs to pgsql-odbc@postgresql.org.
>
> Regards, Dave.
>
>
> Change list
> -----------
>
> - Added SSL support
> - Fix some errors found by static source analysis (using Klocwork). [Tomas Skäre]
> - In SC_pos_reload_needed:2189 rows_per_fetch is uninitialised, if create_from_scratch is false, per Tomas Skäre
> - In SQLGetDescFieldW:128 blen is not initialised before sent to utf8_to_ucs2(). The same thing exists in
SQLColAttributeW:287and SQLGetDiagFieldW:345, per Tomas Skäre
> - Get proper error messages from the server, rather than just saying the database doesn't exist.
> - Japanese GUI update from Hiroshi Saito
> - Include win_unicode.c in Unix build because it contains functions that are used under unix.
> - Fix SQL_MAX_IDENTIFIER_LEN per gborg bug ref: 1348
> - Fix memory leak per gborg bug 1356 [pauldaugherty]
> - Fix unicode copy & convert bug. SQLGetData with SQL_C_WCHAR now returns SQL_SUCCESS once the whole string is sent,
anddoesn't lose odd characters like it did.
> - Fix bug that stopped Use Declare/Fetch working, and prevented ODBC bench running in multi-thread, multi-transaction
mode.
> - Add comment about a known leak bug that needs fixing
> - Handle SQL_DATE from ODBC2 apps, per bug report 1292 [ alic <NOSPAM> sokrates.hr]
> - Fix per bug ref 1187 [Scot Loach]
I got these on compiling the latest CVS
using the RedHat RawHide src.rpm environment:
...
options.c: In function `PGAPI_SetConnectOption':
options.c:500: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
options.c:505: warning: cast to pointer from integer of different size
...
odbcapi30.c: In function `SQLSetEnvAttr':
odbcapi30.c:433: warning: cast from pointer to integer of different size
odbcapi30.c:454: warning: cast from pointer to integer of different size
odbcapi30.c:461: warning: cast from pointer to integer of different size
...
pgapi30.c: In function `ARDSetField':
pgapi30.c:455: warning: cast from pointer to integer of different size
pgapi30.c:464: warning: cast from pointer to integer of different size
pgapi30.c:467: warning: cast from pointer to integer of different size
pgapi30.c:512: warning: cast from pointer to integer of different size
pgapi30.c:521: warning: cast from pointer to integer of different size
pgapi30.c:537: warning: cast from pointer to integer of different size
pgapi30.c:554: warning: cast from pointer to integer of different size
pgapi30.c:557: warning: cast from pointer to integer of different size
pgapi30.c:560: warning: cast from pointer to integer of different size
pgapi30.c: In function `APDSetField':
pgapi30.c:630: warning: cast from pointer to integer of different size
pgapi30.c:639: warning: cast from pointer to integer of different size
pgapi30.c:642: warning: cast from pointer to integer of different size
pgapi30.c:662: warning: cast from pointer to integer of different size
pgapi30.c:671: warning: cast from pointer to integer of different size
pgapi30.c:687: warning: cast from pointer to integer of different size
pgapi30.c:700: warning: cast from pointer to integer of different size
pgapi30.c:706: warning: cast from pointer to integer of different size
pgapi30.c:709: warning: cast from pointer to integer of different size
pgapi30.c: In function `IPDSetField':
pgapi30.c:795: warning: cast from pointer to integer of different size
pgapi30.c:803: warning: cast from pointer to integer of different size
pgapi30.c:822: warning: cast from pointer to integer of different size
pgapi30.c:831: warning: cast from pointer to integer of different size
pgapi30.c:847: warning: cast from pointer to integer of different size
pgapi30.c:850: warning: cast from pointer to integer of different size
pgapi30.c:853: warning: cast from pointer to integer of different size
pgapi30.c: In function `PGAPI_SetConnectAttr':
pgapi30.c:1526: warning: cast from pointer to integer of different size
pgapi30.c:1536: warning: cast from pointer to integer of different size
pgapi30.c: In function `PGAPI_SetStmtAttr':
pgapi30.c:1674: warning: cast from pointer to integer of different size
pgapi30.c:1703: warning: cast from pointer to integer of different size
pgapi30.c:1715: warning: cast from pointer to integer of different size
pgapi30.c:1730: warning: cast from pointer to integer of different size
pgapi30.c:1733: warning: cast from pointer to integer of different size
...
You guessed right, 64 bit system, FC3/x86-64.
Should I worry about these?
I reported it before for 8.00.x and late 7.x.y ODBC versions
and I thought I give it a try again. This statement:
select jk.id,jk.datum,megrend.nev,well.nev,csoport.nev,jk.muszak
from jk left outer join csoport on (csoport.id=jk.csoport),
megrend,well where jk.megr=megrend.id and jk.fpont=well.id;
fails. The application gets the first row, but SQLFetch() returns error
for the second. The other variant of the same statement also fails.
select jk.id,jk.datum,megrend.nev,well.nev,
(select nev from csoport where id=jk.csoport),
jk.muszak from jk,megrend,well where jk.megr=megrend.id and
jk.fpont=well.id;
Simplifying the query by omitting the OUTER JOIN
does not make it work. :-(
select jk.id,jk.datum,megrend.nev,well.nev,jk.muszak from
jk,megrend,well where jk.megr=megrend.id and jk.fpont=well.id;
Uh-oh. Omitting all the fields that may have NULL values fixes it.
Incidentally, the second row already contained NULL fields.
So the problem isn't with complex queries but with NULL values.
I used NULL as the last parameter of SQLBindCol() for every fields
meaning I don't care to be notified about NULL values.
Last thing I tried was to use 3 SQLINTEGER for the 3 fields that may
have NULL values and use &null_val1, etc. as the last parameter
for SQLBindCol(). And it finally fixed it, I get all the rows that
e.g. psql produce for the same query.
I looked quickly at the sources and copy_and_convert_field() in
convert.c has this at line 481:
-----------------------------------------------
if (!value)
{
/*
* handle a null just by returning SQL_NULL_DATA in
pcbValue, and
* doing nothing to the buffer.
*/
if (pcbValue)
{
*((SDWORD *) pcbValueBindRow) = SQL_NULL_DATA;
return COPY_OK;
}
else
{
SC_set_error(stmt,
STMT_RETURN_NULL_WITHOUT_INDICATOR, "StrLen_or_IndPtr was a null pointer
and NULL data was retrieved");
SC_log_error(func, "", stmt);
return SQL_ERROR;
}
}
-----------------------------------------------
unixODBC-2.2.5 sources contains copyies of two very old
ODBC drivers, newer one (reports version 07.01.0003) has this
in copy_and_convert_field() in convert.c, line 228:
-----------------------------------------------
if ( ! value) {
/* handle a null just by returning SQL_NULL_DATA in pcbValue, */
/* and doing nothing to the buffer. */
if(pcbValue) {
*(SDWORD *) ((char *) pcbValue +
pcbValueOffset) = SQL_NULL_DATA;
}
free(tempBuf);
return COPY_OK;
}
-----------------------------------------------
The old version returns COPY_OK for both cases, although the logging
in the new version is nice. Which is the correct behaviour? I would like
to be able to ignore NULL notification.
Best regards,
Zoltán Böszörményi
Zoltan Boszormenyi írta:
> The old version returns COPY_OK for both cases, although the logging
> in the new version is nice. Which is the correct behaviour? I would like
> to be able to ignore NULL notification.
And the attached patch indeed fixes it.
Best regards,
Zoltán Böszörményi
--- psqlodbc-08.01.0103/convert.c.old 2005-08-03 21:24:03.011720344 +0200
+++ psqlodbc-08.01.0103/convert.c 2005-08-03 21:24:19.429224504 +0200
@@ -493,7 +493,7 @@
{
SC_set_error(stmt, STMT_RETURN_NULL_WITHOUT_INDICATOR, "StrLen_or_IndPtr was a null pointer and NULL data
wasretrieved");
SC_log_error(func, "", stmt);
- return SQL_ERROR;
+ return COPY_OK;
}
}
Zoltan Boszormenyi írta: > Zoltan Boszormenyi írta: > >> The old version returns COPY_OK for both cases, although the logging >> in the new version is nice. Which is the correct behaviour? I would like >> to be able to ignore NULL notification. > > > And the attached patch indeed fixes it. And looking up SQLBindCol() in my copy of ODBC 3.5 Developers Guide, it states: * If a NULL pointer is stored in the ValueSize_Indicator parameter, no length or indicator is used. For me, it says that I can use NULL as the last parameter, no matter the fields are NULLs or not. Best regards, Zoltán Böszörményi
> -----Original Message-----
> From: Zoltan Boszormenyi [mailto:zboszor@dunaweb.hu]
> Sent: 03 August 2005 19:08
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] New libpq based driver snapshot
> 08.01.0003 available
>
> I got these on compiling the latest CVS
> using the RedHat RawHide src.rpm environment:
<snip>
>
> You guessed right, 64 bit system, FC3/x86-64.
Well, I guessed 64 bit at least :-) I have an x86-64 FC4 box kicking
around so I'll look into this.
> I used NULL as the last parameter of SQLBindCol() for every fields
> meaning I don't care to be notified about NULL values.
>
> Last thing I tried was to use 3 SQLINTEGER for the 3 fields that may
> have NULL values and use &null_val1, etc. as the last parameter
> for SQLBindCol(). And it finally fixed it, I get all the rows that
> e.g. psql produce for the same query.
>
> I looked quickly at the sources and copy_and_convert_field() in
> convert.c has this at line 481:
>
> -----------------------------------------------
> if (!value)
> {
> /*
> * handle a null just by returning SQL_NULL_DATA in
> pcbValue, and
> * doing nothing to the buffer.
> */
> if (pcbValue)
> {
> *((SDWORD *) pcbValueBindRow) =
> SQL_NULL_DATA;
> return COPY_OK;
> }
> else
> {
> SC_set_error(stmt,
> STMT_RETURN_NULL_WITHOUT_INDICATOR, "StrLen_or_IndPtr was a
> null pointer
> and NULL data was retrieved");
> SC_log_error(func, "", stmt);
> return SQL_ERROR;
> }
> }
> -----------------------------------------------
This is correct from my reading of the spec - specifically, it says:
"If StrLen_or_IndPtr is a null pointer, no length or indicator value is
used. This is an error when fetching data and the data is NULL."
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/ht
m/odbcsqlbindcol.asp
Regards, Dave
Dave Page írta:
>
>>-----Original Message-----
>>From: Zoltan Boszormenyi [mailto:zboszor@dunaweb.hu]
>>Sent: 03 August 2005 19:08
>>To: Dave Page
>>Cc: pgsql-odbc@postgresql.org
>>Subject: Re: [ODBC] New libpq based driver snapshot
>>08.01.0003 available
>>
>>I got these on compiling the latest CVS
>>using the RedHat RawHide src.rpm environment:
>
>
> <snip>
>
>>You guessed right, 64 bit system, FC3/x86-64.
>
>
> Well, I guessed 64 bit at least :-) I have an x86-64 FC4 box kicking
> around so I'll look into this.
>
>
>>I used NULL as the last parameter of SQLBindCol() for every fields
>>meaning I don't care to be notified about NULL values.
>>
>>Last thing I tried was to use 3 SQLINTEGER for the 3 fields that may
>>have NULL values and use &null_val1, etc. as the last parameter
>>for SQLBindCol(). And it finally fixed it, I get all the rows that
>>e.g. psql produce for the same query.
>>
>>I looked quickly at the sources and copy_and_convert_field() in
>>convert.c has this at line 481:
>>
>>-----------------------------------------------
>> if (!value)
>> {
>> /*
>> * handle a null just by returning SQL_NULL_DATA in
>>pcbValue, and
>> * doing nothing to the buffer.
>> */
>> if (pcbValue)
>> {
>> *((SDWORD *) pcbValueBindRow) =
>>SQL_NULL_DATA;
>> return COPY_OK;
>> }
>> else
>> {
>> SC_set_error(stmt,
>>STMT_RETURN_NULL_WITHOUT_INDICATOR, "StrLen_or_IndPtr was a
>>null pointer
>>and NULL data was retrieved");
>> SC_log_error(func, "", stmt);
>> return SQL_ERROR;
>> }
>> }
>>-----------------------------------------------
>
>
> This is correct from my reading of the spec - specifically, it says:
>
> "If StrLen_or_IndPtr is a null pointer, no length or indicator value is
> used. This is an error when fetching data and the data is NULL."
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/ht
> m/odbcsqlbindcol.asp
>
> Regards, Dave
I checked it on our company Informix server (9.21), ODBC driver version:
Informix 3.80.00.10841, released on 2001.04.20. It behaves exactly like
the older PsqlODBC versions, as it does not bother when NULL fields are
passed to the application and SQLBincol(..., NULL) was used.
I remember the same behaviour when I took my database course at the
university in 1993 or '94, an Oracle server was accessed via ODBC
from VC++ (3.x?) application.
And as I said, the wording for the same in ODBC 3.5 Developers Guide
is less strict, and there exist more ODBC drivers that don't handle
this condition as an error. There may be legacy applications where
the same behaviour is expected.
However, PowerBuilder 8.0 seems to work with PsqlODBC-8.01.0003
with my limited testing.
Best regards,
Zoltán Böszörményi
Christof Thalhofer wrote: > Please answer if that solved your problem. No one of the developers > answered directly to my complaints... Christof, here's what I tried: I deinstalled 08.01.0003 driver, clicking on the stored MSI file with the right mouse button and choosing the "Uninstall" option (I didn't succeed to uninstall psqlODBC from the control panel). After deinstallation, there were no C:\WINNT\system32\psqlodbc*.* files left. I rebooted the machine, installed 7.03.02.00 and relinked the tables. I still have the "#Deleted" problem. The problem seem to occour only with tables where a varchar(255) column is part of the primary key. In another table all the cells are filled with label "#Error", the problem seem to be a decimal truncation or something like that. These problems seem to be related with MSAccess 2000, a colleague of mine with Access97 doesn't seem to face this problems. I will try to investigate these problems further and if I find someting interesting I will let you know. Thank you. Kind regards, -- Cris Carampa (cris119@operamail.com) Bologna, 2 agosto 1980. Per non dimenticare: http://www.stragi.it/index.php?pagina=vittime
> I rebooted the machine, installed 7.03.02.00 and relinked the tables. > > I still have the "#Deleted" problem. The problem seem to occour only > with tables where a varchar(255) column is part of the primary key. > > In another table all the cells are filled with label "#Error", the > problem seem to be a decimal truncation or something like that. > > These problems seem to be related with MSAccess 2000, a colleague of > mine with Access97 doesn't seem to face this problems. > > I will try to investigate these problems further and if I find someting > interesting I will let you know. > > Thank you. Kind regards, Probably access has some kind of key limitation. Another way of getting this problem is using high precision timestamps inside the primary key since access can't deal with them on the clientside. Good luck, AFAIK there is no solution to this problem except to work around it. It is more a limitation of access than anything else. Merlin