From: Jojakim <joj...@jo...> - 2013-02-04 10:49:54
|
Dear all - and especially the maintainer, I try to use the SQLxxxW functions and SQL_C_WCHAR type for accissing the driver and discovered problems with string data trucation etc. Are there knows issues with these functions? As, in the past, I already fixed minor problems in the driver, I wanted to fix this problem. After fixing (thought so at least) the string size calculation in OdbcStatement sqlPutData, I discovered other problems. When investigating the code, in my opinion there is an inconsistend handling of i.e. DescRecord length and octetLength fields. To understand the current implementation and what the ODBC standard requires, I started to implement a test suite. While doing this, I raised the SQLGetDescRecord question, which I already posted seperately. What is the experts opinion on how octetLength, length, precision, scale and displaySize should be handled, and what should they containg depending on the FB data type? Thank for any responses to help me understanding and perhaps fixing the driver. --- Joja |
From: Dimitry S. <sd...@ib...> - 2013-02-04 10:58:01
|
04.02.2013 11:25, Jojakim wrote: > What is the experts opinion on how octetLength, length, precision, scale and > displaySize should be handled, and what should they containg depending on the > FB data type? IMHO, standard description is quite clear. For string data length and display size are size in characters while octet length is size in bytes. -- WBR, SD. |
From: Tiesheng W. <t....@qm...> - 2013-02-04 11:01:41
|
OK ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tiesheng Wu Computer Manager Wolfson Institute of Preventive Medicine Queen Mary, University of London Charterhouse Square London EC1M 6BQ Tel: 020 7882 6285 Fax: 020 7882 6270 Email: t....@qm... Web: http://www.wolfson.qmul.ac.uk/ -----Original Message----- From: Dimitry Sibiryakov [mailto:sd...@ib...] Sent: 04 February 2013 10:57 To: fir...@li... Subject: Re: [Firebird-odbc-devel] SQLxxxW functions 04.02.2013 11:25, Jojakim wrote: > What is the experts opinion on how octetLength, length, precision, > scale and displaySize should be handled, and what should they containg > depending on the FB data type? IMHO, standard description is quite clear. For string data length and display size are size in characters while octet length is size in bytes. -- WBR, SD. ---------------------------------------------------------------------------- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ Firebird-odbc-devel mailing list Fir...@li... https://lists.sourceforge.net/lists/listinfo/firebird-odbc-devel |
From: Tiesheng W. <t....@qm...> - 2013-02-04 11:38:16
|
Sorry, I sent out the previous email by mistake. -----Original Message----- From: Tiesheng Wu [mailto:t....@qm...] Sent: 04 February 2013 11:01 To: fir...@li... Subject: Re: [Firebird-odbc-devel] SQLxxxW functions OK ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tiesheng Wu Computer Manager Wolfson Institute of Preventive Medicine Queen Mary, University of London Charterhouse Square London EC1M 6BQ Tel: 020 7882 6285 Fax: 020 7882 6270 Email: t....@qm... Web: http://www.wolfson.qmul.ac.uk/ -----Original Message----- From: Dimitry Sibiryakov [mailto:sd...@ib...] Sent: 04 February 2013 10:57 To: fir...@li... Subject: Re: [Firebird-odbc-devel] SQLxxxW functions 04.02.2013 11:25, Jojakim wrote: > What is the experts opinion on how octetLength, length, precision, > scale and displaySize should be handled, and what should they containg > depending on the FB data type? IMHO, standard description is quite clear. For string data length and display size are size in characters while octet length is size in bytes. -- WBR, SD. ---------------------------------------------------------------------------- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ Firebird-odbc-devel mailing list Fir...@li... https://lists.sourceforge.net/lists/listinfo/firebird-odbc-devel ---------------------------------------------------------------------------- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ Firebird-odbc-devel mailing list Fir...@li... https://lists.sourceforge.net/lists/listinfo/firebird-odbc-devel |
From: Jojakim <joj...@jo...> - 2013-02-04 11:11:02
|
On 04.02.2013 11:56:58, Dimitry Sibiryakov wrote: > 04.02.2013 11:25, Jojakim wrote: >> What is the experts opinion on how octetLength, length, precision, scale and >> displaySize should be handled, and what should they containg depending on the >> FB data type? > > IMHO, standard description is quite clear. For string data length and > display size are size in characters while octet length is size in bytes. > That's right, ODBC standard defines are clear. http://msdn.microsoft.com/en-us/library/windows/desktop/ms712499(v=vs.85).aspx But my question was, how these fields are (or should be) used in the driver sources. Is this like the standard, or do they have some internal meanings or special treatments in special cases. And how should they be set up from the FBs meta data info. -- Joja |
From: Dimitry S. <sd...@ib...> - 2013-02-04 11:19:28
|
04.02.2013 12:10, Jojakim wrote: > But my question was, how these fields are (or should be) used in the driver > sources. Is this like the standard, or do they have some internal meanings or > special treatments in special cases. And how should they be set up from the > FBs meta data info. It depends on coercion between FB data types and ODBC C-types. If, for example, SQL_VARYING is coerced to SQL_C_WCHAR, and FB character set is UTF8, octets length should be = sqllen/2, display length = sqllen/4. For single-byte character sets octets length = sqllen*2, display length = sqllen. Of course, all this in case if WCHAR is stay for UCS2. For UTF-16 I have no idea whet to do if some characters in FB data ends up in four bytes in UTF-16 and how to detect it. -- WBR, SD. |
From: Alexander P. <ale...@gm...> - 2013-02-04 11:13:07
|
Hi, The issues with these functions are unknown. Add information how to reproduce issues into the Tracker - http://tracker.firebirdsql.org/browse/ODBC On 04.02.2013 14:25, Jojakim wrote: > Dear all - and especially the maintainer, > > I try to use the SQLxxxW functions and SQL_C_WCHAR type for accissing the > driver and discovered problems with string data trucation etc. > > Are there knows issues with these functions? > > As, in the past, I already fixed minor problems in the driver, I wanted to > fix this problem. After fixing (thought so at least) the string size > calculation in OdbcStatement sqlPutData, I discovered other problems. When > investigating the code, in my opinion there is an inconsistend handling of > i.e. DescRecord length and octetLength fields. > > To understand the current implementation and what the ODBC standard requires, > I started to implement a test suite. While doing this, I raised the > SQLGetDescRecord question, which I already posted seperately. > > What is the experts opinion on how octetLength, length, precision, scale and > displaySize should be handled, and what should they containg depending on the > FB data type? > > Thank for any responses to help me understanding and perhaps fixing the > driver. > > --- > Joja > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_jan > _______________________________________________ > Firebird-odbc-devel mailing list > Fir...@li... > https://lists.sourceforge.net/lists/listinfo/firebird-odbc-devel |