Menu
▾
▴
firebird-odbc-devel
|
From: Engineering <eng...@as...> - 2009-04-09 15:25:10
Attachments:
fb_odbc_x64_len_fix.zip
|
Hello,
I was not sure where to report bugs/fixes, so I hope this is the right location. This is the issue that we encountered:
On a x64 Windows 2003 machine, using the ODBC driver we attempted to do a selection from a table containing a DateTime column. MFC CRecordSet uses the data lenth to determine if a field is NULL or not for a date-time, and whenever we had the column as NULL, Firebird ODBC seemed to return the 32-bit value 0xFFFFFFFF (which as a 64-bit value is just a very large number), making our selection invalid (MFC actually complains, because the date/time interpreting is not correct).
From what we could tell, the sequence of events is as follows:
- MFC Recordset calls ::SQLBindCol with the length parameter as a "LONG_PTR *" (which is a __int64 **)
- MFC will call ::SQLExtendedFetch, which fills up the length value, however as a 32-bit number (i.e. will be always positive)
I have attached a proposed patch - basically replacing SQLINTEGER with SQLLEN for any index pointers (not sure if this is this the correct term - this is the first time I am messing with this driver). For 32bit this seems to make no difference as the typedefs are the same, however for 64-bit this will change a 32bit value to 64-bit (and would probably need testing). I did test the patch in our environment for date-time columns, however I would appreciate someone more knowledgeable about how the ODBC driver works to take a look. If this can make it into RC2 and/or official release, it would be great.
Regards,
Andrei Litvin
|
|
From: Engineering <eng...@as...> - 2009-04-09 18:18:09
|
I did some further tests .. the attached patch seems to fix the selection but not the prepared statement section (driver crashes with a corrupted heap on statement release). It seems to me that the code assumes that sizeof(long) == 8, which in windows it is not true. On SQLDa.cpp, we have:
....
offset = ROUNDUP (offset, sizeof (int));
indicatorsOffset = offset;
offset += sizeof(long) * numberColumns;
buffer = new char [offset];
lengthBufferRows = offset;
....
And the part that states sizeof(long) should probably be updated to sizeof(SQLLEN). However I see the usage of long in many places where indicators are used, so I am a bit weary of making a trial & error fix. In any case, I will try to make a new patch that would work on selection as well, although I am not that sure how clean it would be.
Andrei
-----Original Message-----
From: Engineering [mailto:eng...@as...]
Sent: Thursday, April 09, 2009 11:24 AM
To: fir...@li...
Subject: [Firebird-odbc-devel] Firebird ODBC: x64 data length compatibility
Hello,
I was not sure where to report bugs/fixes, so I hope this is the right location. This is the issue that we encountered:
On a x64 Windows 2003 machine, using the ODBC driver we attempted to do a selection from a table containing a DateTime column. MFC CRecordSet uses the data lenth to determine if a field is NULL or not for a date-time, and whenever we had the column as NULL, Firebird ODBC seemed to return the 32-bit value 0xFFFFFFFF (which as a 64-bit value is just a very large number), making our selection invalid (MFC actually complains, because the date/time interpreting is not correct).
From what we could tell, the sequence of events is as follows:
- MFC Recordset calls ::SQLBindCol with the length parameter as a "LONG_PTR *" (which is a __int64 **)
- MFC will call ::SQLExtendedFetch, which fills up the length value, however as a 32-bit number (i.e. will be always positive)
I have attached a proposed patch - basically replacing SQLINTEGER with SQLLEN for any index pointers (not sure if this is this the correct term - this is the first time I am messing with this driver). For 32bit this seems to make no difference as the typedefs are the same, however for 64-bit this will change a 32bit value to 64-bit (and would probably need testing). I did test the patch in our environment for date-time columns, however I would appreciate someone more knowledgeable about how the ODBC driver works to take a look. If this can make it into RC2 and/or official release, it would be great.
Regards,
Andrei Litvin
|
|
From: Engineering <eng...@as...> - 2009-04-09 18:23:29
Attachments:
fb_win_x64_len_fix.zip
|
Attached is an updated patch that replaces some more indicator pointers with SQLLEN pointers. Behavior seems much better (i.e. selects with and without parameters seem to work on Win64), however I did by no means go through an exhaustive test.
Andrei
-----Original Message-----
From: Engineering [mailto:eng...@as...]
Sent: Thursday, April 09, 2009 2:08 PM
To: fir...@li...
Subject: Re: [Firebird-odbc-devel] Firebird ODBC: x64 data lengthcompatibility
I did some further tests .. the attached patch seems to fix the selection but not the prepared statement section (driver crashes with a corrupted heap on statement release). It seems to me that the code assumes that sizeof(long) == 8, which in windows it is not true. On SQLDa.cpp, we have:
....
offset = ROUNDUP (offset, sizeof (int));
indicatorsOffset = offset;
offset += sizeof(long) * numberColumns;
buffer = new char [offset];
lengthBufferRows = offset;
....
And the part that states sizeof(long) should probably be updated to sizeof(SQLLEN). However I see the usage of long in many places where indicators are used, so I am a bit weary of making a trial & error fix. In any case, I will try to make a new patch that would work on selection as well, although I am not that sure how clean it would be.
Andrei
-----Original Message-----
From: Engineering [mailto:eng...@as...]
Sent: Thursday, April 09, 2009 11:24 AM
To: fir...@li...
Subject: [Firebird-odbc-devel] Firebird ODBC: x64 data length compatibility
Hello,
I was not sure where to report bugs/fixes, so I hope this is the right location. This is the issue that we encountered:
On a x64 Windows 2003 machine, using the ODBC driver we attempted to do a selection from a table containing a DateTime column. MFC CRecordSet uses the data lenth to determine if a field is NULL or not for a date-time, and whenever we had the column as NULL, Firebird ODBC seemed to return the 32-bit value 0xFFFFFFFF (which as a 64-bit value is just a very large number), making our selection invalid (MFC actually complains, because the date/time interpreting is not correct).
From what we could tell, the sequence of events is as follows:
- MFC Recordset calls ::SQLBindCol with the length parameter as a "LONG_PTR *" (which is a __int64 **)
- MFC will call ::SQLExtendedFetch, which fills up the length value, however as a 32-bit number (i.e. will be always positive)
I have attached a proposed patch - basically replacing SQLINTEGER with SQLLEN for any index pointers (not sure if this is this the correct term - this is the first time I am messing with this driver). For 32bit this seems to make no difference as the typedefs are the same, however for 64-bit this will change a 32bit value to 64-bit (and would probably need testing). I did test the patch in our environment for date-time columns, however I would appreciate someone more knowledgeable about how the ODBC driver works to take a look. If this can make it into RC2 and/or official release, it would be great.
Regards,
Andrei Litvin
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Firebird-odbc-devel mailing list
Fir...@li...
https://lists.sourceforge.net/lists/listinfo/firebird-odbc-devel
|
|
From: Jorge A. B. <jor...@gm...> - 2009-04-22 23:31:41
|
Just FYI, Firebird ODBC has a tracker, located at http://tracker.firebirdsql.org/browse/ODBC Could be a good idea to report the problem and attach the patch there. Regards Engineering escribió: > Attached is an updated patch that replaces some more indicator pointers with SQLLEN pointers. Behavior seems much better (i.e. selects with and without parameters seem to work on Win64), however I did by no means go through an exhaustive test. > > Andrei > > -----Original Message----- > From: Engineering [mailto:eng...@as...] > Sent: Thursday, April 09, 2009 2:08 PM > To: fir...@li... > Subject: Re: [Firebird-odbc-devel] Firebird ODBC: x64 data lengthcompatibility > > I did some further tests .. the attached patch seems to fix the selection but not the prepared statement section (driver crashes with a corrupted heap on statement release). It seems to me that the code assumes that sizeof(long) == 8, which in windows it is not true. On SQLDa.cpp, we have: > .... > offset = ROUNDUP (offset, sizeof (int)); > indicatorsOffset = offset; > offset += sizeof(long) * numberColumns; > buffer = new char [offset]; > lengthBufferRows = offset; > .... > > And the part that states sizeof(long) should probably be updated to sizeof(SQLLEN). However I see the usage of long in many places where indicators are used, so I am a bit weary of making a trial & error fix. In any case, I will try to make a new patch that would work on selection as well, although I am not that sure how clean it would be. > > Andrei > > -----Original Message----- > From: Engineering [mailto:eng...@as...] > Sent: Thursday, April 09, 2009 11:24 AM > To: fir...@li... > Subject: [Firebird-odbc-devel] Firebird ODBC: x64 data length compatibility > > Hello, > > I was not sure where to report bugs/fixes, so I hope this is the right location. This is the issue that we encountered: > > On a x64 Windows 2003 machine, using the ODBC driver we attempted to do a selection from a table containing a DateTime column. MFC CRecordSet uses the data lenth to determine if a field is NULL or not for a date-time, and whenever we had the column as NULL, Firebird ODBC seemed to return the 32-bit value 0xFFFFFFFF (which as a 64-bit value is just a very large number), making our selection invalid (MFC actually complains, because the date/time interpreting is not correct). > > From what we could tell, the sequence of events is as follows: > - MFC Recordset calls ::SQLBindCol with the length parameter as a "LONG_PTR *" (which is a __int64 **) > - MFC will call ::SQLExtendedFetch, which fills up the length value, however as a 32-bit number (i.e. will be always positive) > > I have attached a proposed patch - basically replacing SQLINTEGER with SQLLEN for any index pointers (not sure if this is this the correct term - this is the first time I am messing with this driver). For 32bit this seems to make no difference as the typedefs are the same, however for 64-bit this will change a 32bit value to 64-bit (and would probably need testing). I did test the patch in our environment for date-time columns, however I would appreciate someone more knowledgeable about how the ODBC driver works to take a look. If this can make it into RC2 and/or official release, it would be great. > > Regards, > Andrei Litvin > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > _______________________________________________ > Firebird-odbc-devel mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firebird-odbc-devel > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > ------------------------------------------------------------------------ > > _______________________________________________ > Firebird-odbc-devel mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firebird-odbc-devel > |
|
From: Nikolay S. <nik...@re...> - 2009-04-23 09:38:40
|
Andrei, Jorge, Jorge Andres Brugger wrote: > Just FYI, Firebird ODBC has a tracker, located at > http://tracker.firebirdsql.org/browse/ODBC > > Could be a good idea to report the problem and attach the patch there. > > Regards > > Engineering escribió: >> Attached is an updated patch that replaces some more indicator pointers with SQLLEN pointers. Behavior seems much better (i.e. selects with and without parameters seem to work on Win64), however I did by no means go through an exhaustive test. >> >> Andrei >> The patch seems reasonable to me. I applied it for HEAD and B2_0_0. -- Nikolay Samofatov, MBA Red Soft Corporation +1 416 710 6854 +7 495 721 3537 |
|
From: Engineering <eng...@as...> - 2009-04-23 13:47:16
|
I found the JIRA tracker after a while (did submit a SQL_BIT support patch in the mean time there) .. however that was quite hard to find and I found the ODBC devel list instead. Since I got the message from Nikolay that the patch was applied to 2.0, I guess I can skip the posting in the tracker, however I will add any new patches there. Thank you for the info. What are firebird developers likely to check - the devel list or the tracker? The tracker seems to have few issues, but some of them seem really ancient. Regards, Andrei From: Jorge Andres Brugger [mailto:jor...@gm...] Sent: Wednesday, April 22, 2009 7:31 PM To: fir...@li... Subject: [Suspected Spam] Re: [Firebird-odbc-devel] Firebird ODBC: x64data lengthcompatibility Just FYI, Firebird ODBC has a tracker, located at http://tracker.firebirdsql.org/browse/ODBC Could be a good idea to report the problem and attach the patch there. Regards Engineering escribió: Attached is an updated patch that replaces some more indicator pointers with SQLLEN pointers. Behavior seems much better (i.e. selects with and without parameters seem to work on Win64), however I did by no means go through an exhaustive test. Andrei -----Original Message----- From: Engineering [mailto:eng...@as...] Sent: Thursday, April 09, 2009 2:08 PM To: fir...@li... Subject: Re: [Firebird-odbc-devel] Firebird ODBC: x64 data lengthcompatibility I did some further tests .. the attached patch seems to fix the selection but not the prepared statement section (driver crashes with a corrupted heap on statement release). It seems to me that the code assumes that sizeof(long) == 8, which in windows it is not true. On SQLDa.cpp, we have: .... offset = ROUNDUP (offset, sizeof (int)); indicatorsOffset = offset; offset += sizeof(long) * numberColumns; buffer = new char [offset]; lengthBufferRows = offset; .... And the part that states sizeof(long) should probably be updated to sizeof(SQLLEN). However I see the usage of long in many places where indicators are used, so I am a bit weary of making a trial & error fix. In any case, I will try to make a new patch that would work on selection as well, although I am not that sure how clean it would be. Andrei -----Original Message----- From: Engineering [mailto:eng...@as...] Sent: Thursday, April 09, 2009 11:24 AM To: fir...@li... Subject: [Firebird-odbc-devel] Firebird ODBC: x64 data length compatibility Hello, I was not sure where to report bugs/fixes, so I hope this is the right location. This is the issue that we encountered: On a x64 Windows 2003 machine, using the ODBC driver we attempted to do a selection from a table containing a DateTime column. MFC CRecordSet uses the data lenth to determine if a field is NULL or not for a date-time, and whenever we had the column as NULL, Firebird ODBC seemed to return the 32-bit value 0xFFFFFFFF (which as a 64-bit value is just a very large number), making our selection invalid (MFC actually complains, because the date/time interpreting is not correct). From what we could tell, the sequence of events is as follows: - MFC Recordset calls ::SQLBindCol with the length parameter as a "LONG_PTR *" (which is a __int64 **) - MFC will call ::SQLExtendedFetch, which fills up the length value, however as a 32-bit number (i.e. will be always positive) I have attached a proposed patch - basically replacing SQLINTEGER with SQLLEN for any index pointers (not sure if this is this the correct term - this is the first time I am messing with this driver). For 32bit this seems to make no difference as the typedefs are the same, however for 64-bit this will change a 32bit value to 64-bit (and would probably need testing). I did test the patch in our environment for date-time columns, however I would appreciate someone more knowledgeable about how the ODBC driver works to take a look. If this can make it into RC2 and/or official release, it would be great. Regards, Andrei Litvin ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Firebird-odbc-devel mailing list Fir...@li... https://lists.sourceforge.net/lists/listinfo/firebird-odbc-devel ________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ________________________________ _______________________________________________ Firebird-odbc-devel mailing list Fir...@li... https://lists.sourceforge.net/lists/listinfo/firebird-odbc-devel |
|
From: Nikolay S. <nik...@re...> - 2009-04-23 18:36:01
|
Andrei, Engineering wrote: > > I found the JIRA tracker after a while (did submit a SQL_BIT support > patch in the mean time there) .. however that was quite hard to find > and I found the ODBC devel list instead. Since I got the message from > Nikolay that the patch was applied to 2.0, I guess I can skip the > posting in the tracker, however I will add any new patches there. > Thank you for the info. > > What are firebird developers likely to check – the devel list or the > tracker? The tracker seems to have few issues, but some of them seem > really ancient. > Myself and other guys from our lab (e.g. Roman Simakov) I know read odbc devel mailing list regularly. However if everyone is busy, some messages may be left unprocessed. If an item is posted to the tracker only it will get some attention for sure, but it is checked less frequently. Re SQL_BIT, I may apply this patch to HEAD. But could you please attach patch file to an issue instead of placing it inline as comments - it does not apply cleanly at this moment. > Regards, > > Andrei > -- Nikolay Samofatov, MBA Red Soft Corporation +1 416 710 6854 +7 495 721 3537 |
|
From: Engineering <eng...@as...> - 2009-04-23 18:46:01
Attachments:
fb_odbc_sql_c_bit.diff
|
I tried to attach the patch, however for some reason the "attach" did not work (was using Google Chrome at the time, I think). I have attached the patch here, however with some reservations: - this patch just makes SQL_C_BIT treatment as a TinyInt for output. This may work in Windows, because of BOOL == int, however I do not know if this is the general case. May be a better idea to have BOOL == char (and at least on little-endian systems will not really care). - the change would assume that only 1 or 0 can be inside the selection, however it will happily transfer 2,3,4 and so on (which is hardly a BIT). I did consider writing a "tinyIntAsBit" which would make 0 == 0 and non-zero == 1, however for our internal functions we did not need it so I ended up with this fairly dirty hack. Regards, Andrei -----Original Message----- From: Nikolay Samofatov [mailto:nik...@re...] Sent: Thursday, April 23, 2009 2:36 PM To: fir...@li... Subject: Re: [Firebird-odbc-devel] [Suspected Spam] Re: Firebird ODBC: x64data lengthcompatibility Andrei, Engineering wrote: > > I found the JIRA tracker after a while (did submit a SQL_BIT support > patch in the mean time there) .. however that was quite hard to find > and I found the ODBC devel list instead. Since I got the message from > Nikolay that the patch was applied to 2.0, I guess I can skip the > posting in the tracker, however I will add any new patches there. > Thank you for the info. > > What are firebird developers likely to check - the devel list or the > tracker? The tracker seems to have few issues, but some of them seem > really ancient. > Myself and other guys from our lab (e.g. Roman Simakov) I know read odbc devel mailing list regularly. However if everyone is busy, some messages may be left unprocessed. If an item is posted to the tracker only it will get some attention for sure, but it is checked less frequently. Re SQL_BIT, I may apply this patch to HEAD. But could you please attach patch file to an issue instead of placing it inline as comments - it does not apply cleanly at this moment. > Regards, > > Andrei > -- Nikolay Samofatov, MBA Red Soft Corporation +1 416 710 6854 +7 495 721 3537 ------------------------------------------------------------------------ ------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Firebird-odbc-devel mailing list Fir...@li... https://lists.sourceforge.net/lists/listinfo/firebird-odbc-devel |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X