Opened 16 years ago
Closed 16 years ago
#1902 closed defect (fixed)
Data truncation sometimes occurs when fetching data using ogr odbc driver
Reported by: | pgerritson | Owned by: | Mateusz Łoskot |
---|---|---|---|
Priority: | normal | Milestone: | 1.4.3 |
Component: | OGR_SF | Version: | svn-trunk |
Severity: | normal | Keywords: | odbc |
Cc: | warmerdam |
Description
In cpl_odbc.cpp, in CPLODBCStatement::Fetch, when the column fetch_type is SQL_C_CHAR and the column data is exactly 511 characters long, the data is returned missing the last character.
In this case, the initial SQLGetData call on line 836 returns SQL_SUCCESS_WITH_INFO, and cbDataLen is 511, and szWrkData has the first 510 characters plus a binary 0 at index 510.
It seems that the bug is due to an improper edge condition on line 859: if( cbDataLen > (_SQLLEN)(sizeof(szWrkData)-1) )
In this case, when cbDataLen is exactly 511, this "if" condition is not satisfied, and the code labelled " trimming the extra terminators: bug 990" does not get executed.
The next call to SQLGetData (on line 864) correctly reads the last character of the field, but the memcpy on line 907 places this last character at index 511, after the binary zero at index 510.
Changing the "if" statement on line 859 to be : if( cbDataLen >= (_SQLLEN)(sizeof(szWrkData)-1) ) seems to fix the problem.
Attachments (2)
Change History (6)
comment:1 by , 16 years ago
Cc: | added |
---|---|
Component: | default → OGR_SF |
Keywords: | odbc added |
Milestone: | → 1.4.3 |
Owner: | changed from | to
comment:2 by , 16 years ago
Status: | new → assigned |
---|
pgerritson,
Could you tell me what operating system and ODBC layer do you use? Is it Windows or Unix + unixODBC or yet another combination?
by , 16 years ago
Attachment: | test_data.sql added |
---|
Single-record dataset that was used to reproduce and confirm the truncation problem
comment:4 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Version: | unspecified → svn-trunk |
Mateusz,
The described bug and fix seem reasonable to me, but could you try and reproduce the problem and verify the fix before applying it? The fix should go into 1.4 as well as trunk.