Menu
▾
▴
libodbcxx-devel — libodbc++ development
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(43) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(28) |
Feb
(6) |
Mar
(13) |
Apr
(10) |
May
(12) |
Jun
(14) |
Jul
(12) |
Aug
|
Sep
(32) |
Oct
(8) |
Nov
(6) |
Dec
(25) |
| 2005 |
Jan
(3) |
Feb
(26) |
Mar
(1) |
Apr
(40) |
May
(6) |
Jun
(2) |
Jul
(9) |
Aug
(5) |
Sep
(24) |
Oct
(8) |
Nov
(21) |
Dec
(6) |
| 2006 |
Jan
(17) |
Feb
(10) |
Mar
(3) |
Apr
|
May
(18) |
Jun
(2) |
Jul
(9) |
Aug
(4) |
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2007 |
Jan
|
Feb
|
Mar
(1) |
Apr
(8) |
May
(2) |
Jun
|
Jul
(4) |
Aug
(2) |
Sep
(29) |
Oct
(15) |
Nov
(1) |
Dec
(1) |
| 2008 |
Jan
(2) |
Feb
|
Mar
(6) |
Apr
(1) |
May
(4) |
Jun
(13) |
Jul
(1) |
Aug
(3) |
Sep
|
Oct
(5) |
Nov
(7) |
Dec
(1) |
| 2009 |
Jan
(9) |
Feb
(4) |
Mar
(2) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
(8) |
Sep
(11) |
Oct
(4) |
Nov
|
Dec
(20) |
| 2010 |
Jan
(9) |
Feb
(1) |
Mar
(2) |
Apr
(8) |
May
(3) |
Jun
(8) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
(3) |
Feb
(3) |
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(4) |
Dec
(5) |
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(2) |
Jun
(10) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Mark K. <gre...@ma...> - 2009-12-29 11:28:35
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If we do a presence/absence test, then it would be better. I think as far as a cmake it somewhat easy, but my ac/m4 skills are not that great. I mainly use CMake at work so I am much more familiar with it. The other option that we could do is to drop the legacy stuff, but that would affect some people still using gcc 3 and maybe vc6. Regards, Mark Kromis. On 2009/12/29, at 6:15, MANUEL TEIRA PAZ wrote: > > ________________________________________ > De: Mark Kromis [gre...@ma...] > Enviado el: lunes, 28 de diciembre de 2009 19:51 > Para: libodbc++ development mailing list > Asunto: Re: [libodbcxx-devel] Fwd: DataHandler: unhandled SQL type 0 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Greetings, > > IMHO, patch 005...nonconst sets the iterator to a non-const. I believe this to be more correct then when it was. Having a const in an iterator should be a const_iterator. So I had no problem with that. > > The patch 003...string_percent tweaks a string, but since none of the library is i18n yet this will need to be looked at later. > > The last patch seems to use more modern headers, and it seems at the time of writing those headers were not used in some compilers. So what I think should be done is to make the modern headers the default, and turn on the define for the old headers for compilers that need them, like GCC < 4. > > I'm still looking to see what GCC 3 uses. > > Perhaps this should be checked in configure in some other way, looking for a concrete feature, and not relying in a compiler version. The way it is done now only works for GNU toolchains, adding more compilers will lead to a ifdef/ifndef hell in my opinion. So, why not just look for the presence of what is actually needed in configure time? > > Just my two cents. > > Regards. > > > Feedback? > > Regards, > Mark Kromis > > On 2009/12/28, at 10:50, Tommaso Massimi wrote: > >> Hi, >> >> I agree that there is somethings strange in that patch, >> as ODBCXX_HAVE_ISO_CXXLIB is used also in some other files: >> >> libodbc++-0.2.5/include/odbc++$grep ODBCXX_HAVE_ISO_CXXLIB * >> config-win32.h:# define ODBCXX_HAVE_ISO_CXXLIB >> config-win32.h:# define ODBCXX_HAVE_ISO_CXXLIB >> preparedstatement.h:#if defined(ODBCXX_HAVE_ISO_CXXLIB) >> setup.h:# define ODBCXX_HAVE_ISO_CXXLIB >> >> in include/odbc++/setup.h I can read >> >> // this should do the trick >> #if defined(__GNUC__) && __GNUC__>=3 >> # define ODBCXX_HAVE_ISO_CXXLIB >> #endif >> >> (I think here __GNUC__ should be replaced by __GNUG__, >> and this could let unuseful the patch) >> >> In preparedstatement.h the define ODBCXX_HAVE_ISO_CXXLIB is only >> changing an include: >> >> #if defined(ODBCXX_HAVE_ISO_CXXLIB) >> # include <iosfwd> >> #else >> # include <iostream> >> #endif >> >> The other 2 patches seems useful only when using the solaris compiler >> >> Regards >> Tom >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> libodbcxx-devel mailing list >> lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (Darwin) > > iEYEARECAAYFAks4/ioACgkQ74ci1S6/F5+oxgCeM2xhCaS3cteg7i1TxLCnor5p > 748AnReHj1RtfzBCBaRhCOZ18ySCsAb4 > =dpc8 > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > libodbcxx-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > libodbcxx-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAks559QACgkQ74ci1S6/F59LbACgtxMjFxpT8UDuCpY+S5aGGC5a UhgAn1EPl6UIDgpaSTgfqWb5VKzxkW6j =3LVc -----END PGP SIGNATURE----- |
|
From: MANUEL T. P. <mt...@ti...> - 2009-12-29 11:19:55
|
________________________________________ De: Mark Kromis [gre...@ma...] Enviado el: lunes, 28 de diciembre de 2009 19:51 Para: libodbc++ development mailing list Asunto: Re: [libodbcxx-devel] Fwd: DataHandler: unhandled SQL type 0 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, IMHO, patch 005...nonconst sets the iterator to a non-const. I believe this to be more correct then when it was. Having a const in an iterator should be a const_iterator. So I had no problem with that. The patch 003...string_percent tweaks a string, but since none of the library is i18n yet this will need to be looked at later. The last patch seems to use more modern headers, and it seems at the time of writing those headers were not used in some compilers. So what I think should be done is to make the modern headers the default, and turn on the define for the old headers for compilers that need them, like GCC < 4. I'm still looking to see what GCC 3 uses. Perhaps this should be checked in configure in some other way, looking for a concrete feature, and not relying in a compiler version. The way it is done now only works for GNU toolchains, adding more compilers will lead to a ifdef/ifndef hell in my opinion. So, why not just look for the presence of what is actually needed in configure time? Just my two cents. Regards. Feedback? Regards, Mark Kromis On 2009/12/28, at 10:50, Tommaso Massimi wrote: > Hi, > > I agree that there is somethings strange in that patch, > as ODBCXX_HAVE_ISO_CXXLIB is used also in some other files: > > libodbc++-0.2.5/include/odbc++$grep ODBCXX_HAVE_ISO_CXXLIB * > config-win32.h:# define ODBCXX_HAVE_ISO_CXXLIB > config-win32.h:# define ODBCXX_HAVE_ISO_CXXLIB > preparedstatement.h:#if defined(ODBCXX_HAVE_ISO_CXXLIB) > setup.h:# define ODBCXX_HAVE_ISO_CXXLIB > > in include/odbc++/setup.h I can read > > // this should do the trick > #if defined(__GNUC__) && __GNUC__>=3 > # define ODBCXX_HAVE_ISO_CXXLIB > #endif > > (I think here __GNUC__ should be replaced by __GNUG__, > and this could let unuseful the patch) > > In preparedstatement.h the define ODBCXX_HAVE_ISO_CXXLIB is only > changing an include: > > #if defined(ODBCXX_HAVE_ISO_CXXLIB) > # include <iosfwd> > #else > # include <iostream> > #endif > > The other 2 patches seems useful only when using the solaris compiler > > Regards > Tom > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > libodbcxx-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAks4/ioACgkQ74ci1S6/F5+oxgCeM2xhCaS3cteg7i1TxLCnor5p 748AnReHj1RtfzBCBaRhCOZ18ySCsAb4 =dpc8 -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ libodbcxx-devel mailing list lib...@li... https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel |
|
From: Mark K. <gre...@ma...> - 2009-12-28 18:51:52
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, IMHO, patch 005...nonconst sets the iterator to a non-const. I believe this to be more correct then when it was. Having a const in an iterator should be a const_iterator. So I had no problem with that. The patch 003...string_percent tweaks a string, but since none of the library is i18n yet this will need to be looked at later. The last patch seems to use more modern headers, and it seems at the time of writing those headers were not used in some compilers. So what I think should be done is to make the modern headers the default, and turn on the define for the old headers for compilers that need them, like GCC < 4. I'm still looking to see what GCC 3 uses. Feedback? Regards, Mark Kromis On 2009/12/28, at 10:50, Tommaso Massimi wrote: > Hi, > > I agree that there is somethings strange in that patch, > as ODBCXX_HAVE_ISO_CXXLIB is used also in some other files: > > libodbc++-0.2.5/include/odbc++$grep ODBCXX_HAVE_ISO_CXXLIB * > config-win32.h:# define ODBCXX_HAVE_ISO_CXXLIB > config-win32.h:# define ODBCXX_HAVE_ISO_CXXLIB > preparedstatement.h:#if defined(ODBCXX_HAVE_ISO_CXXLIB) > setup.h:# define ODBCXX_HAVE_ISO_CXXLIB > > in include/odbc++/setup.h I can read > > // this should do the trick > #if defined(__GNUC__) && __GNUC__>=3 > # define ODBCXX_HAVE_ISO_CXXLIB > #endif > > (I think here __GNUC__ should be replaced by __GNUG__, > and this could let unuseful the patch) > > In preparedstatement.h the define ODBCXX_HAVE_ISO_CXXLIB is only > changing an include: > > #if defined(ODBCXX_HAVE_ISO_CXXLIB) > # include <iosfwd> > #else > # include <iostream> > #endif > > The other 2 patches seems useful only when using the solaris compiler > > Regards > Tom > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > libodbcxx-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAks4/ioACgkQ74ci1S6/F5+oxgCeM2xhCaS3cteg7i1TxLCnor5p 748AnReHj1RtfzBCBaRhCOZ18ySCsAb4 =dpc8 -----END PGP SIGNATURE----- |
|
From: Tommaso M. <tma...@gm...> - 2009-12-28 15:51:00
|
Hi, I agree that there is somethings strange in that patch, as ODBCXX_HAVE_ISO_CXXLIB is used also in some other files: libodbc++-0.2.5/include/odbc++$grep ODBCXX_HAVE_ISO_CXXLIB * config-win32.h:# define ODBCXX_HAVE_ISO_CXXLIB config-win32.h:# define ODBCXX_HAVE_ISO_CXXLIB preparedstatement.h:#if defined(ODBCXX_HAVE_ISO_CXXLIB) setup.h:# define ODBCXX_HAVE_ISO_CXXLIB in include/odbc++/setup.h I can read // this should do the trick #if defined(__GNUC__) && __GNUC__>=3 # define ODBCXX_HAVE_ISO_CXXLIB #endif (I think here __GNUC__ should be replaced by __GNUG__, and this could let unuseful the patch) In preparedstatement.h the define ODBCXX_HAVE_ISO_CXXLIB is only changing an include: #if defined(ODBCXX_HAVE_ISO_CXXLIB) # include <iosfwd> #else # include <iostream> #endif The other 2 patches seems useful only when using the solaris compiler Regards Tom |
|
From: Manuel T. <mt...@ti...> - 2009-12-28 15:42:55
|
El 25/12/2009 1:10, Mark Kromis escribió: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello Manuel, > > Regarding patch 004_iso... This should have been dealt with in setup.h for unix platforms. What compiler are you using? > I applied the other two patches in to svn. > Hello, Mark. First of all, I should mention that I'm using a libodbc++ 0.2.4pre4 tarball. Probably the svn version has changed slightly from that tarball. My compiler is Sun Studio 12. I've also seen the mail about your commit. Actually those are not my patches, but extracted from the debian packager. Anyway, I think it is good to have them added upstream. Thanks, regards, happy new year. Manuel. > Regards, > Mark Kromis. > > > On 2009/12/23, at 14:51, Manuel Teira wrote: > > >> Hello, Tomasso. >> Now that you told me about the problems building odbc++, I remembered that I took some of the patches from debian packages, to make life easier. I'm attaching to this mail the patches I'm using to build odbc++. >> I hope this will be useful. >> >> >> Regards. >> >> >> >> El 23/12/2009 15:45, Tommaso Massimi escribió: >> >>> thanks Manulel, >>> very useful information. >>> >>> Now I have built 64bit unixodbc and I'm trying to build 64bit libodbc++ >>> >>> configure went fine >>> (this is my configure line >>> CPPFLAGS=-m64 CFLAGS=-m64 LD_LIBRARY_PATH=/usr/local/lib ./configure >>> --with-odbc=/usr/local --without-qt --without-isqlxx) >>> >>> but make had problem with ODBCXX_STRING_PERCENT (not present in the >>> source code) >>> and, after fixed it, make complains about different size of an element: >>> >>> /opt/GCC-4.3.2/bin/ld: Warning: size of symbol `std::vector<int, >>> std::allocator<int> >>> >>> >>>> ::_M_insert_aux(__gnu_cxx::__normal_iterator<int*, std::vector<int, >>>> >>>> >>> std::allocator<int> > >, int const&)' changed from 320 in >>> .libs/preparedstatement.o to 316 in .libs/resultsetmetadata.o >>> >>> That's realluy strange but could explain what I saw. >>> I'll investigate more later, for now it's enough. >>> >>> Have a nice Xmas >>> Tom >>> >>> PS: for the curios person, more details from my compilation >>> It's also strange that "/usr/local/lib/libodbc.so: could not read >>> symbols: File in wrong format", >>> as "file /usr/local/lib/libodbc.so >>> ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped" >>> >>> >>> /bin/bash ../libtool --tag=CXX --mode=link g++ -DIN_ODBCXX >>> -D_GNU_SOURCE -g -O2 -version-info 4:0:0 -o libodbc++.la -rpath >>> /usr/local/lib threads.lo datetime.lo driverinfo.lo drivermanager.lo >>> connection.lo databasemetadata.lo statement.lo preparedstatement.lo >>> callablestatement.lo resultset.lo resultsetmetadata.lo errorhandler.lo >>> datahandler.lo datastream.lo -L/usr/local/lib -lodbc >>> g++ -shared -nostdlib >>> /opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/sparcv9/crti.o >>> /usr/ccs/lib/sparcv9/values-Xa.o >>> /opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/sparcv9/crtbegin.o >>> .libs/threads.o .libs/datetime.o .libs/driverinfo.o >>> .libs/drivermanager.o .libs/connection.o .libs/databasemetadata.o >>> .libs/statement.o .libs/preparedstatement.o .libs/callablestatement.o >>> .libs/resultset.o .libs/resultsetmetadata.o .libs/errorhandler.o >>> .libs/datahandler.o .libs/datastream.o -Wl,--rpath -Wl,/usr/local/lib >>> -Wl,--rpath -Wl,/usr/local/lib/. -Wl,--rpath -Wl,/usr/local/lib >>> -Wl,--rpath -Wl,/usr/local/lib/. -L/usr/local/lib >>> /usr/local/lib/libodbc.so >>> -L/opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/sparcv9 >>> -L/usr/ccs/lib/sparcv9 >>> -L/opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/../../../sparcv9 >>> -L/lib/sparcv9 -L/usr/lib/sparcv9 >>> -L/opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2 >>> -L/opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/../../../../sparc-sun-solaris2.10/lib >>> -L/usr/ccs/lib -L/opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/../../.. >>> /usr/local/lib/./libstdc++.so >>> -L/usr2/SOURCES/S10/gcc-3.3.2/objdir/sparc-sun-solaris2.10/libstdc++-v3/src >>> -L/usr2/SOURCES/S10/gcc-3.3.2/objdir/sparc-sun-solaris2.10/libstdc++-v3/src/.libs >>> -L/usr2/SOURCES/S10/gcc-3.3.2/objdir/gcc -L/usr/ccs/bin >>> -L/usr/local/lib/gcc-lib/.. -lm -lgcc_s >>> /opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/sparcv9/crtend.o >>> /opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/sparcv9/crtn.o >>> -Wl,-soname -Wl,libodbc++.so.4 -o .libs/libodbc++.so.4.0.0 >>> /opt/GCC-4.3.2/bin/ld: Warning: size of symbol `std::vector<int, >>> std::allocator<int> >>> >>> >>>> ::_M_insert_aux(__gnu_cxx::__normal_iterator<int*, std::vector<int, >>>> >>>> >>> std::allocator<int> > >, int const&)' changed from 320 in >>> .libs/preparedstatement.o to 316 in .libs/resultsetmetadata.o >>> /usr/local/lib/libodbc.so: could not read symbols: File in wrong format >>> >>> ------------------------------------------------------------------------------ >>> This SF.Net email is sponsored by the Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution fast and easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> libodbcxx-devel mailing list >>> lib...@li... >>> https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel >>> >>> >> >> <005_resultsetmetadata-nonconst.patch><003_odbcxx_string_percent.patch><004_iso_cxxlib.patch>------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ >> libodbcxx-devel mailing list >> lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (Darwin) > > iEYEARECAAYFAks0AwIACgkQ74ci1S6/F58hhQCfTwMJt+/+hzMOTBiVRPHPY4od > aj4AoIzRExxbqtr59CvkGBy0+EkvIzWY > =3cJY > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > libodbcxx-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel > |
|
From: Mark K. <gre...@ma...> - 2009-12-25 01:12:43
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Commits from mail lists.
- src/resultsetmetadata.cpp removed const from map iterator.
- src/dtconv.h cnaged ODBC_STRING_PERCENT to use % symbol
* contributed from Manuel Teira <mteira at tid.es>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (Darwin)
iEYEARECAAYFAks0A2gACgkQ74ci1S6/F5/5/QCeM1M8hH5ninf02XWXOZth16W9
aWYAn1LGg2exMxXZB28xj2fJ7MsFlZ46
=nkg2
-----END PGP SIGNATURE-----
|
|
From: Mark K. <gre...@ma...> - 2009-12-25 00:11:01
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Manuel, Regarding patch 004_iso... This should have been dealt with in setup.h for unix platforms. What compiler are you using? I applied the other two patches in to svn. Regards, Mark Kromis. On 2009/12/23, at 14:51, Manuel Teira wrote: > Hello, Tomasso. > Now that you told me about the problems building odbc++, I remembered that I took some of the patches from debian packages, to make life easier. I'm attaching to this mail the patches I'm using to build odbc++. > I hope this will be useful. > > > Regards. > > > > El 23/12/2009 15:45, Tommaso Massimi escribió: >> thanks Manulel, >> very useful information. >> >> Now I have built 64bit unixodbc and I'm trying to build 64bit libodbc++ >> >> configure went fine >> (this is my configure line >> CPPFLAGS=-m64 CFLAGS=-m64 LD_LIBRARY_PATH=/usr/local/lib ./configure >> --with-odbc=/usr/local --without-qt --without-isqlxx) >> >> but make had problem with ODBCXX_STRING_PERCENT (not present in the >> source code) >> and, after fixed it, make complains about different size of an element: >> >> /opt/GCC-4.3.2/bin/ld: Warning: size of symbol `std::vector<int, >> std::allocator<int> >> >>> ::_M_insert_aux(__gnu_cxx::__normal_iterator<int*, std::vector<int, >>> >> std::allocator<int> > >, int const&)' changed from 320 in >> .libs/preparedstatement.o to 316 in .libs/resultsetmetadata.o >> >> That's realluy strange but could explain what I saw. >> I'll investigate more later, for now it's enough. >> >> Have a nice Xmas >> Tom >> >> PS: for the curios person, more details from my compilation >> It's also strange that "/usr/local/lib/libodbc.so: could not read >> symbols: File in wrong format", >> as "file /usr/local/lib/libodbc.so >> ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped" >> >> >> /bin/bash ../libtool --tag=CXX --mode=link g++ -DIN_ODBCXX >> -D_GNU_SOURCE -g -O2 -version-info 4:0:0 -o libodbc++.la -rpath >> /usr/local/lib threads.lo datetime.lo driverinfo.lo drivermanager.lo >> connection.lo databasemetadata.lo statement.lo preparedstatement.lo >> callablestatement.lo resultset.lo resultsetmetadata.lo errorhandler.lo >> datahandler.lo datastream.lo -L/usr/local/lib -lodbc >> g++ -shared -nostdlib >> /opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/sparcv9/crti.o >> /usr/ccs/lib/sparcv9/values-Xa.o >> /opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/sparcv9/crtbegin.o >> .libs/threads.o .libs/datetime.o .libs/driverinfo.o >> .libs/drivermanager.o .libs/connection.o .libs/databasemetadata.o >> .libs/statement.o .libs/preparedstatement.o .libs/callablestatement.o >> .libs/resultset.o .libs/resultsetmetadata.o .libs/errorhandler.o >> .libs/datahandler.o .libs/datastream.o -Wl,--rpath -Wl,/usr/local/lib >> -Wl,--rpath -Wl,/usr/local/lib/. -Wl,--rpath -Wl,/usr/local/lib >> -Wl,--rpath -Wl,/usr/local/lib/. -L/usr/local/lib >> /usr/local/lib/libodbc.so >> -L/opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/sparcv9 >> -L/usr/ccs/lib/sparcv9 >> -L/opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/../../../sparcv9 >> -L/lib/sparcv9 -L/usr/lib/sparcv9 >> -L/opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2 >> -L/opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/../../../../sparc-sun-solaris2.10/lib >> -L/usr/ccs/lib -L/opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/../../.. >> /usr/local/lib/./libstdc++.so >> -L/usr2/SOURCES/S10/gcc-3.3.2/objdir/sparc-sun-solaris2.10/libstdc++-v3/src >> -L/usr2/SOURCES/S10/gcc-3.3.2/objdir/sparc-sun-solaris2.10/libstdc++-v3/src/.libs >> -L/usr2/SOURCES/S10/gcc-3.3.2/objdir/gcc -L/usr/ccs/bin >> -L/usr/local/lib/gcc-lib/.. -lm -lgcc_s >> /opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/sparcv9/crtend.o >> /opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/sparcv9/crtn.o >> -Wl,-soname -Wl,libodbc++.so.4 -o .libs/libodbc++.so.4.0.0 >> /opt/GCC-4.3.2/bin/ld: Warning: size of symbol `std::vector<int, >> std::allocator<int> >> >>> ::_M_insert_aux(__gnu_cxx::__normal_iterator<int*, std::vector<int, >>> >> std::allocator<int> > >, int const&)' changed from 320 in >> .libs/preparedstatement.o to 316 in .libs/resultsetmetadata.o >> /usr/local/lib/libodbc.so: could not read symbols: File in wrong format >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> libodbcxx-devel mailing list >> lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel >> > > > <005_resultsetmetadata-nonconst.patch><003_odbcxx_string_percent.patch><004_iso_cxxlib.patch>------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ > libodbcxx-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAks0AwIACgkQ74ci1S6/F58hhQCfTwMJt+/+hzMOTBiVRPHPY4od aj4AoIzRExxbqtr59CvkGBy0+EkvIzWY =3cJY -----END PGP SIGNATURE----- |
|
From: Manuel T. <mt...@ti...> - 2009-12-23 19:51:28
|
Hello, Tomasso. Now that you told me about the problems building odbc++, I remembered that I took some of the patches from debian packages, to make life easier. I'm attaching to this mail the patches I'm using to build odbc++. I hope this will be useful. Regards. El 23/12/2009 15:45, Tommaso Massimi escribió: > thanks Manulel, > very useful information. > > Now I have built 64bit unixodbc and I'm trying to build 64bit libodbc++ > > configure went fine > (this is my configure line > CPPFLAGS=-m64 CFLAGS=-m64 LD_LIBRARY_PATH=/usr/local/lib ./configure > --with-odbc=/usr/local --without-qt --without-isqlxx) > > but make had problem with ODBCXX_STRING_PERCENT (not present in the > source code) > and, after fixed it, make complains about different size of an element: > > /opt/GCC-4.3.2/bin/ld: Warning: size of symbol `std::vector<int, > std::allocator<int> > >> ::_M_insert_aux(__gnu_cxx::__normal_iterator<int*, std::vector<int, >> > std::allocator<int> > >, int const&)' changed from 320 in > .libs/preparedstatement.o to 316 in .libs/resultsetmetadata.o > > That's realluy strange but could explain what I saw. > I'll investigate more later, for now it's enough. > > Have a nice Xmas > Tom > > PS: for the curios person, more details from my compilation > It's also strange that "/usr/local/lib/libodbc.so: could not read > symbols: File in wrong format", > as "file /usr/local/lib/libodbc.so > ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped" > > > /bin/bash ../libtool --tag=CXX --mode=link g++ -DIN_ODBCXX > -D_GNU_SOURCE -g -O2 -version-info 4:0:0 -o libodbc++.la -rpath > /usr/local/lib threads.lo datetime.lo driverinfo.lo drivermanager.lo > connection.lo databasemetadata.lo statement.lo preparedstatement.lo > callablestatement.lo resultset.lo resultsetmetadata.lo errorhandler.lo > datahandler.lo datastream.lo -L/usr/local/lib -lodbc > g++ -shared -nostdlib > /opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/sparcv9/crti.o > /usr/ccs/lib/sparcv9/values-Xa.o > /opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/sparcv9/crtbegin.o > .libs/threads.o .libs/datetime.o .libs/driverinfo.o > .libs/drivermanager.o .libs/connection.o .libs/databasemetadata.o > .libs/statement.o .libs/preparedstatement.o .libs/callablestatement.o > .libs/resultset.o .libs/resultsetmetadata.o .libs/errorhandler.o > .libs/datahandler.o .libs/datastream.o -Wl,--rpath -Wl,/usr/local/lib > -Wl,--rpath -Wl,/usr/local/lib/. -Wl,--rpath -Wl,/usr/local/lib > -Wl,--rpath -Wl,/usr/local/lib/. -L/usr/local/lib > /usr/local/lib/libodbc.so > -L/opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/sparcv9 > -L/usr/ccs/lib/sparcv9 > -L/opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/../../../sparcv9 > -L/lib/sparcv9 -L/usr/lib/sparcv9 > -L/opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2 > -L/opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/../../../../sparc-sun-solaris2.10/lib > -L/usr/ccs/lib -L/opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/../../.. > /usr/local/lib/./libstdc++.so > -L/usr2/SOURCES/S10/gcc-3.3.2/objdir/sparc-sun-solaris2.10/libstdc++-v3/src > -L/usr2/SOURCES/S10/gcc-3.3.2/objdir/sparc-sun-solaris2.10/libstdc++-v3/src/.libs > -L/usr2/SOURCES/S10/gcc-3.3.2/objdir/gcc -L/usr/ccs/bin > -L/usr/local/lib/gcc-lib/.. -lm -lgcc_s > /opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/sparcv9/crtend.o > /opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/sparcv9/crtn.o > -Wl,-soname -Wl,libodbc++.so.4 -o .libs/libodbc++.so.4.0.0 > /opt/GCC-4.3.2/bin/ld: Warning: size of symbol `std::vector<int, > std::allocator<int> > >> ::_M_insert_aux(__gnu_cxx::__normal_iterator<int*, std::vector<int, >> > std::allocator<int> > >, int const&)' changed from 320 in > .libs/preparedstatement.o to 316 in .libs/resultsetmetadata.o > /usr/local/lib/libodbc.so: could not read symbols: File in wrong format > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > libodbcxx-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel > |
|
From: Tommaso M. <tma...@gm...> - 2009-12-23 14:45:52
|
thanks Manulel, very useful information. Now I have built 64bit unixodbc and I'm trying to build 64bit libodbc++ configure went fine (this is my configure line CPPFLAGS=-m64 CFLAGS=-m64 LD_LIBRARY_PATH=/usr/local/lib ./configure --with-odbc=/usr/local --without-qt --without-isqlxx) but make had problem with ODBCXX_STRING_PERCENT (not present in the source code) and, after fixed it, make complains about different size of an element: /opt/GCC-4.3.2/bin/ld: Warning: size of symbol `std::vector<int, std::allocator<int> >::_M_insert_aux(__gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >, int const&)' changed from 320 in .libs/preparedstatement.o to 316 in .libs/resultsetmetadata.o That's realluy strange but could explain what I saw. I'll investigate more later, for now it's enough. Have a nice Xmas Tom PS: for the curios person, more details from my compilation It's also strange that "/usr/local/lib/libodbc.so: could not read symbols: File in wrong format", as "file /usr/local/lib/libodbc.so ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped" /bin/bash ../libtool --tag=CXX --mode=link g++ -DIN_ODBCXX -D_GNU_SOURCE -g -O2 -version-info 4:0:0 -o libodbc++.la -rpath /usr/local/lib threads.lo datetime.lo driverinfo.lo drivermanager.lo connection.lo databasemetadata.lo statement.lo preparedstatement.lo callablestatement.lo resultset.lo resultsetmetadata.lo errorhandler.lo datahandler.lo datastream.lo -L/usr/local/lib -lodbc g++ -shared -nostdlib /opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/sparcv9/crti.o /usr/ccs/lib/sparcv9/values-Xa.o /opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/sparcv9/crtbegin.o .libs/threads.o .libs/datetime.o .libs/driverinfo.o .libs/drivermanager.o .libs/connection.o .libs/databasemetadata.o .libs/statement.o .libs/preparedstatement.o .libs/callablestatement.o .libs/resultset.o .libs/resultsetmetadata.o .libs/errorhandler.o .libs/datahandler.o .libs/datastream.o -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib/. -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib/. -L/usr/local/lib /usr/local/lib/libodbc.so -L/opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/sparcv9 -L/usr/ccs/lib/sparcv9 -L/opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/../../../sparcv9 -L/lib/sparcv9 -L/usr/lib/sparcv9 -L/opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2 -L/opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/../../../../sparc-sun-solaris2.10/lib -L/usr/ccs/lib -L/opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/../../.. /usr/local/lib/./libstdc++.so -L/usr2/SOURCES/S10/gcc-3.3.2/objdir/sparc-sun-solaris2.10/libstdc++-v3/src -L/usr2/SOURCES/S10/gcc-3.3.2/objdir/sparc-sun-solaris2.10/libstdc++-v3/src/.libs -L/usr2/SOURCES/S10/gcc-3.3.2/objdir/gcc -L/usr/ccs/bin -L/usr/local/lib/gcc-lib/.. -lm -lgcc_s /opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/sparcv9/crtend.o /opt/GCC-4.3.2/lib/gcc/sparc-sun-solaris2.10/4.3.2/sparcv9/crtn.o -Wl,-soname -Wl,libodbc++.so.4 -o .libs/libodbc++.so.4.0.0 /opt/GCC-4.3.2/bin/ld: Warning: size of symbol `std::vector<int, std::allocator<int> >::_M_insert_aux(__gnu_cxx::__normal_iterator<int*, std::vector<int, std::allocator<int> > >, int const&)' changed from 320 in .libs/preparedstatement.o to 316 in .libs/resultsetmetadata.o /usr/local/lib/libodbc.so: could not read symbols: File in wrong format |
|
From: MANUEL T. P. <mt...@ti...> - 2009-12-19 08:36:38
|
________________________________________
De: Tommaso Massimi [tma...@gm...]
Enviado el: viernes, 18 de diciembre de 2009 19:04
Para: libodbc++ development mailing list
Asunto: Re: [libodbcxx-devel] Fwd: DataHandler: unhandled SQL type 0
Hi Manuel,
many thanks for your answer.
You're welcome. Find my answers below.
Unlikely I'm already using unixodbc version 2.2.14,
so I have nothing to change on that part.
But I think you can help me answering to these few questions:
are you using an Intel or a Sparc Solaris 10?
A sparc one.
did you compile unixodbc by yourself or are you using the downloaded packages?
I compiled it myself, using Sun Studio 12.
are you using the default version of the ODBC protocol or you forced
libodbc++ to use an older ODBC protocol version?
I'm using the default one.
Thaks a lot in advance
Hope this helps.
Regards.
Manuel.
Tom
On Wed, Dec 16, 2009 at 6:47 PM, Manuel Teira <mt...@ti...> wrote:
> Hello.
> I think I've suffered similar problems in my tests with 64bit solaris.
> IIRC SQLLEN was changed from 4 bytes to 8 bytes in unixodbc recently. I
> noticed the change from 2.2.12 to 2.2.14.
>
> Hope it helps.
>
>
> Regards.
>
>
> El 16/12/2009 18:17, Tommaso Massimi escribió:
>> Hi again,
>> I have added a printf in the _getNumericAttribute function,
>> and rebuilt the library on both linux and solaris.
>>
>> here the results:
>>
>> === Linux intel 32 bit ===
>> excuting Select * FROM `tomTable`
>> col=1, attr=1001, res=1
>> col=1, attr=2, res=4
>> col=1, attr=1005, res=10
>> col=1, attr=1006, res=0
>> col=1, attr=1003, res=10
>>
>> === SPARC Solaris 64 bit ===
>> excuting Select * FROM `tomTable`
>> col=1, attr=1001, res=1
>> col=1, attr=2, res=17179869184
>> col=1, attr=1005, res=42949672960
>> col=1, attr=1006, res=0
>> col=1, attr=1003, res=10
>> [libodbc++]: DataHandler: unhandled SQL type 0
>>
>> 17179869184 = 0x400000000 ( 4 and 8 zeros)
>> 42949672960 = 0xA00000000 (A and 8 zeros)
>>
>> so it seems in some case the function SQLColAttribute fails,
>> but probably the fault is in unixodbc,
>> I'll try to post these results on their mail list.
>>
>> Sorry for the noise.
>> Tom
>>
>> ---------- Forwarded message ----------
>> From: Tommaso Massimi<tma...@gm...>
>> Date: Wed, Dec 16, 2009 at 12:27 PM
>> Subject: DataHandler: unhandled SQL type 0
>> To: lib...@li...
>>
>>
>> Hi,
>>
>> I have built libodbc++ 0.2.5 on a Linux machine (32 bit) with gcc,
>> using unixodbc and mysql-connector,
>> and I'm able to perform all the queries I need to do for my application.
>>
>> Then I built the same libodbc++ sources on a Solaris SPARC machine (64
>> bit) with CC,
>> using the same version of unixodbc and mysql-connector,
>> but on this configuration some query fails,
>> and each time a query fails I see on the console the message
>> "DataHandler: unhandled SQL type 0" so I think this is related to my problem.
>>
>> This is the sequence of queries I'm doing:
>>
>> "DROP DATABASE if exists tom"
>> "CREATE DATABASE tom"
>> "use tom"
>> "DROP TABLE IF EXISTS `tomTable`"
>> "CREATE TABLE `tomTable` ( `Stato` int NOT NULL default '0' ) "
>> "insert into `tomTable` ( `Stato`) VALUES ("4")"
>> "UPDATE `tomTable` set `Stato`= "55" where `Stato`='"4"'"
>> "Select * FROM `tomTable`"
>>
>> I have verified all the queries are succesful except the last one,
>> which prints on the console the error message
>> "DataHandler: unhandled SQL type 0"
>>
>> So I started a debug session:
>> the message comes from the DataHandler constructor,
>> as it can't manage the passed sqltype =0
>>
>> that value sqltype =0 is loaded from the DB in these lines,
>>
>> void ResultSetMetaData::_fetchColumnInfo()
>> {
>> //first argument is ignored
>> numCols_=this->_getNumericAttribute
>> (1,ODBC3_DC(SQL_DESC_COUNT,SQL_COLUMN_COUNT));
>>
>> for(int i=1; i<=numCols_; i++) {
>> colNames_.push_back(this->_getStringAttribute
>> (i,ODBC3_DC(SQL_DESC_NAME,SQL_COLUMN_NAME)));
>> #ifdef ODBCXX_USE_INDEXED_METADATA_COLNAMES
>> colNameIndex_.insert(make_pair(colNames_[i-1], i));
>> #endif // ODBCXX_USE_INDEXED_METADATA_COLNAMES
>> // int colType=this->_getNumericAttribute
>> // (i,ODBC3_DC(SQL_DESC_CONCISE_TYPE,SQL_COLUMN_TYPE));
>> int colType=REMAP_DATATYPE(this->_getNumericAttribute
>> (i,ODBC3_DC(SQL_DESC_CONCISE_TYPE,SQL_COLUMN_TYPE)));
>>
>> colTypes_.push_back(colType);
>>
>> I can see the rigth field name loaded in the colNameIndex_ map
>> and the wrong col type 0 returned by the function _getNumericAttribute
>> and not remapped by REMAP_DATATYPE.
>>
>> _getNumericAttribute receives params col=1and attr=2
>>
>> here the code:
>>
>> //private
>> int ResultSetMetaData::_getNumericAttribute(unsigned int col,
>> SQLUSMALLINT attr)
>> {
>> SQLLEN res=0;
>> SQLRETURN r=
>> ODBC3_C(SQLColAttribute,SQLColAttributes)(resultSet_->hstmt_,
>> (SQLUSMALLINT)col,
>> attr,
>> 0,
>> 0,
>> 0,
>> &res);
>> resultSet_->_checkStmtError(resultSet_->hstmt_,
>> r,ODBCXX_STRING_CONST("Error fetching
>> numeric attribute"));
>> return (int)res;
>> }
>>
>> the variable s res is setted by ODBC3_C function to the value
>> 0x400000000 (4 and 8 zeros) but casted to int become 0.
>>
>> I'm not sure if this is a fault (and expecially, the fault I'm looking for),
>> may I have your opinion about it?
>> Could it be an endianess trouble in the value setted by ODBC3_C?
>>
>> Thanks
>> Tom
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> libodbcxx-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> libodbcxx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel
>
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
libodbcxx-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel
|
|
From: Tommaso M. <tma...@gm...> - 2009-12-18 18:04:52
|
Hi Manuel,
many thanks for your answer.
Unlikely I'm already using unixodbc version 2.2.14,
so I have nothing to change on that part.
But I think you can help me answering to these few questions:
are you using an Intel or a Sparc Solaris 10?
did you compile unixodbc by yourself or are you using the downloaded packages?
are you using the default version of the ODBC protocol or you forced
libodbc++ to use an older ODBC protocol version?
Thaks a lot in advance
Tom
On Wed, Dec 16, 2009 at 6:47 PM, Manuel Teira <mt...@ti...> wrote:
> Hello.
> I think I've suffered similar problems in my tests with 64bit solaris.
> IIRC SQLLEN was changed from 4 bytes to 8 bytes in unixodbc recently. I
> noticed the change from 2.2.12 to 2.2.14.
>
> Hope it helps.
>
>
> Regards.
>
>
> El 16/12/2009 18:17, Tommaso Massimi escribió:
>> Hi again,
>> I have added a printf in the _getNumericAttribute function,
>> and rebuilt the library on both linux and solaris.
>>
>> here the results:
>>
>> === Linux intel 32 bit ===
>> excuting Select * FROM `tomTable`
>> col=1, attr=1001, res=1
>> col=1, attr=2, res=4
>> col=1, attr=1005, res=10
>> col=1, attr=1006, res=0
>> col=1, attr=1003, res=10
>>
>> === SPARC Solaris 64 bit ===
>> excuting Select * FROM `tomTable`
>> col=1, attr=1001, res=1
>> col=1, attr=2, res=17179869184
>> col=1, attr=1005, res=42949672960
>> col=1, attr=1006, res=0
>> col=1, attr=1003, res=10
>> [libodbc++]: DataHandler: unhandled SQL type 0
>>
>> 17179869184 = 0x400000000 ( 4 and 8 zeros)
>> 42949672960 = 0xA00000000 (A and 8 zeros)
>>
>> so it seems in some case the function SQLColAttribute fails,
>> but probably the fault is in unixodbc,
>> I'll try to post these results on their mail list.
>>
>> Sorry for the noise.
>> Tom
>>
>> ---------- Forwarded message ----------
>> From: Tommaso Massimi<tma...@gm...>
>> Date: Wed, Dec 16, 2009 at 12:27 PM
>> Subject: DataHandler: unhandled SQL type 0
>> To: lib...@li...
>>
>>
>> Hi,
>>
>> I have built libodbc++ 0.2.5 on a Linux machine (32 bit) with gcc,
>> using unixodbc and mysql-connector,
>> and I'm able to perform all the queries I need to do for my application.
>>
>> Then I built the same libodbc++ sources on a Solaris SPARC machine (64
>> bit) with CC,
>> using the same version of unixodbc and mysql-connector,
>> but on this configuration some query fails,
>> and each time a query fails I see on the console the message
>> "DataHandler: unhandled SQL type 0" so I think this is related to my problem.
>>
>> This is the sequence of queries I'm doing:
>>
>> "DROP DATABASE if exists tom"
>> "CREATE DATABASE tom"
>> "use tom"
>> "DROP TABLE IF EXISTS `tomTable`"
>> "CREATE TABLE `tomTable` ( `Stato` int NOT NULL default '0' ) "
>> "insert into `tomTable` ( `Stato`) VALUES ("4")"
>> "UPDATE `tomTable` set `Stato`= "55" where `Stato`='"4"'"
>> "Select * FROM `tomTable`"
>>
>> I have verified all the queries are succesful except the last one,
>> which prints on the console the error message
>> "DataHandler: unhandled SQL type 0"
>>
>> So I started a debug session:
>> the message comes from the DataHandler constructor,
>> as it can't manage the passed sqltype =0
>>
>> that value sqltype =0 is loaded from the DB in these lines,
>>
>> void ResultSetMetaData::_fetchColumnInfo()
>> {
>> //first argument is ignored
>> numCols_=this->_getNumericAttribute
>> (1,ODBC3_DC(SQL_DESC_COUNT,SQL_COLUMN_COUNT));
>>
>> for(int i=1; i<=numCols_; i++) {
>> colNames_.push_back(this->_getStringAttribute
>> (i,ODBC3_DC(SQL_DESC_NAME,SQL_COLUMN_NAME)));
>> #ifdef ODBCXX_USE_INDEXED_METADATA_COLNAMES
>> colNameIndex_.insert(make_pair(colNames_[i-1], i));
>> #endif // ODBCXX_USE_INDEXED_METADATA_COLNAMES
>> // int colType=this->_getNumericAttribute
>> // (i,ODBC3_DC(SQL_DESC_CONCISE_TYPE,SQL_COLUMN_TYPE));
>> int colType=REMAP_DATATYPE(this->_getNumericAttribute
>> (i,ODBC3_DC(SQL_DESC_CONCISE_TYPE,SQL_COLUMN_TYPE)));
>>
>> colTypes_.push_back(colType);
>>
>> I can see the rigth field name loaded in the colNameIndex_ map
>> and the wrong col type 0 returned by the function _getNumericAttribute
>> and not remapped by REMAP_DATATYPE.
>>
>> _getNumericAttribute receives params col=1and attr=2
>>
>> here the code:
>>
>> //private
>> int ResultSetMetaData::_getNumericAttribute(unsigned int col,
>> SQLUSMALLINT attr)
>> {
>> SQLLEN res=0;
>> SQLRETURN r=
>> ODBC3_C(SQLColAttribute,SQLColAttributes)(resultSet_->hstmt_,
>> (SQLUSMALLINT)col,
>> attr,
>> 0,
>> 0,
>> 0,
>> &res);
>> resultSet_->_checkStmtError(resultSet_->hstmt_,
>> r,ODBCXX_STRING_CONST("Error fetching
>> numeric attribute"));
>> return (int)res;
>> }
>>
>> the variable s res is setted by ODBC3_C function to the value
>> 0x400000000 (4 and 8 zeros) but casted to int become 0.
>>
>> I'm not sure if this is a fault (and expecially, the fault I'm looking for),
>> may I have your opinion about it?
>> Could it be an endianess trouble in the value setted by ODBC3_C?
>>
>> Thanks
>> Tom
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> libodbcxx-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> libodbcxx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel
>
|
|
From: Manuel T. <mt...@ti...> - 2009-12-16 17:48:03
|
Hello.
I think I've suffered similar problems in my tests with 64bit solaris.
IIRC SQLLEN was changed from 4 bytes to 8 bytes in unixodbc recently. I
noticed the change from 2.2.12 to 2.2.14.
Hope it helps.
Regards.
El 16/12/2009 18:17, Tommaso Massimi escribió:
> Hi again,
> I have added a printf in the _getNumericAttribute function,
> and rebuilt the library on both linux and solaris.
>
> here the results:
>
> === Linux intel 32 bit ===
> excuting Select * FROM `tomTable`
> col=1, attr=1001, res=1
> col=1, attr=2, res=4
> col=1, attr=1005, res=10
> col=1, attr=1006, res=0
> col=1, attr=1003, res=10
>
> === SPARC Solaris 64 bit ===
> excuting Select * FROM `tomTable`
> col=1, attr=1001, res=1
> col=1, attr=2, res=17179869184
> col=1, attr=1005, res=42949672960
> col=1, attr=1006, res=0
> col=1, attr=1003, res=10
> [libodbc++]: DataHandler: unhandled SQL type 0
>
> 17179869184 = 0x400000000 ( 4 and 8 zeros)
> 42949672960 = 0xA00000000 (A and 8 zeros)
>
> so it seems in some case the function SQLColAttribute fails,
> but probably the fault is in unixodbc,
> I'll try to post these results on their mail list.
>
> Sorry for the noise.
> Tom
>
> ---------- Forwarded message ----------
> From: Tommaso Massimi<tma...@gm...>
> Date: Wed, Dec 16, 2009 at 12:27 PM
> Subject: DataHandler: unhandled SQL type 0
> To: lib...@li...
>
>
> Hi,
>
> I have built libodbc++ 0.2.5 on a Linux machine (32 bit) with gcc,
> using unixodbc and mysql-connector,
> and I'm able to perform all the queries I need to do for my application.
>
> Then I built the same libodbc++ sources on a Solaris SPARC machine (64
> bit) with CC,
> using the same version of unixodbc and mysql-connector,
> but on this configuration some query fails,
> and each time a query fails I see on the console the message
> "DataHandler: unhandled SQL type 0" so I think this is related to my problem.
>
> This is the sequence of queries I'm doing:
>
> "DROP DATABASE if exists tom"
> "CREATE DATABASE tom"
> "use tom"
> "DROP TABLE IF EXISTS `tomTable`"
> "CREATE TABLE `tomTable` ( `Stato` int NOT NULL default '0' ) "
> "insert into `tomTable` ( `Stato`) VALUES ("4")"
> "UPDATE `tomTable` set `Stato`= "55" where `Stato`='"4"'"
> "Select * FROM `tomTable`"
>
> I have verified all the queries are succesful except the last one,
> which prints on the console the error message
> "DataHandler: unhandled SQL type 0"
>
> So I started a debug session:
> the message comes from the DataHandler constructor,
> as it can't manage the passed sqltype =0
>
> that value sqltype =0 is loaded from the DB in these lines,
>
> void ResultSetMetaData::_fetchColumnInfo()
> {
> //first argument is ignored
> numCols_=this->_getNumericAttribute
> (1,ODBC3_DC(SQL_DESC_COUNT,SQL_COLUMN_COUNT));
>
> for(int i=1; i<=numCols_; i++) {
> colNames_.push_back(this->_getStringAttribute
> (i,ODBC3_DC(SQL_DESC_NAME,SQL_COLUMN_NAME)));
> #ifdef ODBCXX_USE_INDEXED_METADATA_COLNAMES
> colNameIndex_.insert(make_pair(colNames_[i-1], i));
> #endif // ODBCXX_USE_INDEXED_METADATA_COLNAMES
> // int colType=this->_getNumericAttribute
> // (i,ODBC3_DC(SQL_DESC_CONCISE_TYPE,SQL_COLUMN_TYPE));
> int colType=REMAP_DATATYPE(this->_getNumericAttribute
> (i,ODBC3_DC(SQL_DESC_CONCISE_TYPE,SQL_COLUMN_TYPE)));
>
> colTypes_.push_back(colType);
>
> I can see the rigth field name loaded in the colNameIndex_ map
> and the wrong col type 0 returned by the function _getNumericAttribute
> and not remapped by REMAP_DATATYPE.
>
> _getNumericAttribute receives params col=1and attr=2
>
> here the code:
>
> //private
> int ResultSetMetaData::_getNumericAttribute(unsigned int col,
> SQLUSMALLINT attr)
> {
> SQLLEN res=0;
> SQLRETURN r=
> ODBC3_C(SQLColAttribute,SQLColAttributes)(resultSet_->hstmt_,
> (SQLUSMALLINT)col,
> attr,
> 0,
> 0,
> 0,
> &res);
> resultSet_->_checkStmtError(resultSet_->hstmt_,
> r,ODBCXX_STRING_CONST("Error fetching
> numeric attribute"));
> return (int)res;
> }
>
> the variable s res is setted by ODBC3_C function to the value
> 0x400000000 (4 and 8 zeros) but casted to int become 0.
>
> I'm not sure if this is a fault (and expecially, the fault I'm looking for),
> may I have your opinion about it?
> Could it be an endianess trouble in the value setted by ODBC3_C?
>
> Thanks
> Tom
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> libodbcxx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel
>
|
|
From: Tommaso M. <tma...@gm...> - 2009-12-16 17:17:58
|
Hi again,
I have added a printf in the _getNumericAttribute function,
and rebuilt the library on both linux and solaris.
here the results:
=== Linux intel 32 bit ===
excuting Select * FROM `tomTable`
col=1, attr=1001, res=1
col=1, attr=2, res=4
col=1, attr=1005, res=10
col=1, attr=1006, res=0
col=1, attr=1003, res=10
=== SPARC Solaris 64 bit ===
excuting Select * FROM `tomTable`
col=1, attr=1001, res=1
col=1, attr=2, res=17179869184
col=1, attr=1005, res=42949672960
col=1, attr=1006, res=0
col=1, attr=1003, res=10
[libodbc++]: DataHandler: unhandled SQL type 0
17179869184 = 0x400000000 ( 4 and 8 zeros)
42949672960 = 0xA00000000 (A and 8 zeros)
so it seems in some case the function SQLColAttribute fails,
but probably the fault is in unixodbc,
I'll try to post these results on their mail list.
Sorry for the noise.
Tom
---------- Forwarded message ----------
From: Tommaso Massimi <tma...@gm...>
Date: Wed, Dec 16, 2009 at 12:27 PM
Subject: DataHandler: unhandled SQL type 0
To: lib...@li...
Hi,
I have built libodbc++ 0.2.5 on a Linux machine (32 bit) with gcc,
using unixodbc and mysql-connector,
and I'm able to perform all the queries I need to do for my application.
Then I built the same libodbc++ sources on a Solaris SPARC machine (64
bit) with CC,
using the same version of unixodbc and mysql-connector,
but on this configuration some query fails,
and each time a query fails I see on the console the message
"DataHandler: unhandled SQL type 0" so I think this is related to my problem.
This is the sequence of queries I'm doing:
"DROP DATABASE if exists tom"
"CREATE DATABASE tom"
"use tom"
"DROP TABLE IF EXISTS `tomTable`"
"CREATE TABLE `tomTable` ( `Stato` int NOT NULL default '0' ) "
"insert into `tomTable` ( `Stato`) VALUES ("4")"
"UPDATE `tomTable` set `Stato`= "55" where `Stato`='"4"'"
"Select * FROM `tomTable`"
I have verified all the queries are succesful except the last one,
which prints on the console the error message
"DataHandler: unhandled SQL type 0"
So I started a debug session:
the message comes from the DataHandler constructor,
as it can't manage the passed sqltype =0
that value sqltype =0 is loaded from the DB in these lines,
void ResultSetMetaData::_fetchColumnInfo()
{
//first argument is ignored
numCols_=this->_getNumericAttribute
(1,ODBC3_DC(SQL_DESC_COUNT,SQL_COLUMN_COUNT));
for(int i=1; i<=numCols_; i++) {
colNames_.push_back(this->_getStringAttribute
(i,ODBC3_DC(SQL_DESC_NAME,SQL_COLUMN_NAME)));
#ifdef ODBCXX_USE_INDEXED_METADATA_COLNAMES
colNameIndex_.insert(make_pair(colNames_[i-1], i));
#endif // ODBCXX_USE_INDEXED_METADATA_COLNAMES
// int colType=this->_getNumericAttribute
// (i,ODBC3_DC(SQL_DESC_CONCISE_TYPE,SQL_COLUMN_TYPE));
int colType=REMAP_DATATYPE(this->_getNumericAttribute
(i,ODBC3_DC(SQL_DESC_CONCISE_TYPE,SQL_COLUMN_TYPE)));
colTypes_.push_back(colType);
I can see the rigth field name loaded in the colNameIndex_ map
and the wrong col type 0 returned by the function _getNumericAttribute
and not remapped by REMAP_DATATYPE.
_getNumericAttribute receives params col=1and attr=2
here the code:
//private
int ResultSetMetaData::_getNumericAttribute(unsigned int col,
SQLUSMALLINT attr)
{
SQLLEN res=0;
SQLRETURN r=
ODBC3_C(SQLColAttribute,SQLColAttributes)(resultSet_->hstmt_,
(SQLUSMALLINT)col,
attr,
0,
0,
0,
&res);
resultSet_->_checkStmtError(resultSet_->hstmt_,
r,ODBCXX_STRING_CONST("Error fetching
numeric attribute"));
return (int)res;
}
the variable s res is setted by ODBC3_C function to the value
0x400000000 (4 and 8 zeros) but casted to int become 0.
I'm not sure if this is a fault (and expecially, the fault I'm looking for),
may I have your opinion about it?
Could it be an endianess trouble in the value setted by ODBC3_C?
Thanks
Tom
|
|
From: Tommaso M. <tma...@gm...> - 2009-12-16 11:28:24
|
Hi,
I have built libodbc++ 0.2.5 on a Linux machine (32 bit) with gcc,
using unixodbc and mysql-connector,
and I'm able to perform all the queries I need to do for my application.
Then I built the same libodbc++ sources on a Solaris SPARC machine (64
bit) with CC,
using the same version of unixodbc and mysql-connector,
but on this configuration some query fails,
and each time a query fails I see on the console the message
"DataHandler: unhandled SQL type 0" so I think this is related to my problem.
This is the sequence of queries I'm doing:
"DROP DATABASE if exists tom"
"CREATE DATABASE tom"
"use tom"
"DROP TABLE IF EXISTS `tomTable`"
"CREATE TABLE `tomTable` ( `Stato` int NOT NULL default '0' ) "
"insert into `tomTable` ( `Stato`) VALUES ("4")"
"UPDATE `tomTable` set `Stato`= "55" where `Stato`='"4"'"
"Select * FROM `tomTable`"
I have verified all the queries are succesful except the last one,
which prints on the console the error message
"DataHandler: unhandled SQL type 0"
So I started a debug session:
the message comes from the DataHandler constructor,
as it can't manage the passed sqltype =0
that value sqltype =0 is loaded from the DB in these lines,
void ResultSetMetaData::_fetchColumnInfo()
{
//first argument is ignored
numCols_=this->_getNumericAttribute
(1,ODBC3_DC(SQL_DESC_COUNT,SQL_COLUMN_COUNT));
for(int i=1; i<=numCols_; i++) {
colNames_.push_back(this->_getStringAttribute
(i,ODBC3_DC(SQL_DESC_NAME,SQL_COLUMN_NAME)));
#ifdef ODBCXX_USE_INDEXED_METADATA_COLNAMES
colNameIndex_.insert(make_pair(colNames_[i-1], i));
#endif // ODBCXX_USE_INDEXED_METADATA_COLNAMES
// int colType=this->_getNumericAttribute
// (i,ODBC3_DC(SQL_DESC_CONCISE_TYPE,SQL_COLUMN_TYPE));
int colType=REMAP_DATATYPE(this->_getNumericAttribute
(i,ODBC3_DC(SQL_DESC_CONCISE_TYPE,SQL_COLUMN_TYPE)));
colTypes_.push_back(colType);
I can see the rigth field name loaded in the colNameIndex_ map
and the wrong col type 0 returned by the function _getNumericAttribute
and not remapped by REMAP_DATATYPE.
_getNumericAttribute receives params col=1and attr=2
here the code:
//private
int ResultSetMetaData::_getNumericAttribute(unsigned int col,
SQLUSMALLINT attr)
{
SQLLEN res=0;
SQLRETURN r=
ODBC3_C(SQLColAttribute,SQLColAttributes)(resultSet_->hstmt_,
(SQLUSMALLINT)col,
attr,
0,
0,
0,
&res);
resultSet_->_checkStmtError(resultSet_->hstmt_,
r,ODBCXX_STRING_CONST("Error fetching numeric attribute"));
return (int)res;
}
the variable s res is setted by ODBC3_C function to the value
0x400000000 (4 and 8 zeros) but casted to int become 0.
I'm not sure if this is a fault (and expecially, the fault I'm looking for),
may I have your opinion about it?
Could it be an endianess trouble in the value setted by ODBC3_C?
Thanks
Tom
|
|
From: Mark K. <gre...@ma...> - 2009-12-15 09:50:54
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 i'm going to look into this some more. Oracle 64 seems to be payware. So I'm going to try mysql, and some others in 64-bit mode to see if Oracle is an exception. For 64-bit sizes most unixes follow LP64, windows follows LLP64. See http://en.wikipedia.org/wiki/64-bit#Specific_data_models i'm setting some open source databases to test. Regards, Mark Kromis On 2009/12/14, at 11:15, Manuel Teira wrote: > Hello. Some more data into the issue. > > Testing with the following table: > > create table integer_test(myint number not null); > > I created a ODBC program trying to insert a value into the table, and > showing it later. I will omit all the tedious ODBC code, but the effect > with odbc++ and integer types can be reproduced. This code: > > SQLINTEGER intValue = 55; > r = SQLBindParameter(hstmt, > (SQLUSMALLINT) 1, > (SQLSMALLINT) SQL_PARAM_INPUT, > (SQLSMALLINT) SQL_C_LONG, > (SQLSMALLINT) SQL_INTEGER, > 0, 0, &intValue, 0, 0); > > to execute the sentence > > INSERT INTO INTEGER_TEST(MYINT) VALUES (?) > > Is inserting 236223201280. > > But changing the intValue type to long (8 bytes in solaris 64 bits) the > value is inserted correctly as 55. > > So, it seems to me that the Oracle driver expects SQL_C_LONG values into > a 8 bytes buffer. Unfortunately, I don't know if this is the expected > behaviour, or how to change the odbc++ code to cleanly honour this need. > Probably, drivers should honour SQLINTEGER size for these values, but > Oracle is expecting a long here. The first question that arises is: > What size should a SQLINTEGER have in a 64 bits platform? > Have all 64 bit platforms the same definitions than Solaris for int and > long (4 and 8 bytes respectively) ? > > Best regards. > > > > > > Manuel Teira escribió: >> Hello again. >> Unfortunately, my last tests with the new driver were not creating >> entries into the table (I commented out the creation, deletion and fill >> of the table values to focus on data fetching). >> Once I've checked with the whole program again, I've found that I've got >> a problem with insertions, it seems to me that it is related with data >> wide expected by the oracle driver or something so: >> >> -bash-3.00$ ./odbc-integer-test >> >> Connecting to DSN=backenddb;uid=foo;pwd=bar >> Error performing tests: Error executing "insert into >> TEST_ODBC_INTEGER(myid, myint) values(?,?)": >> [Oracle][ODBC][Ora]ORA-01438: value larger than specified precision >> allowed for this column >> >> Finished. >> >> This problem arises while trying to fill the MYINT column, defined as >> NUMBER(5). If precision is not specified, the program runs correctly, >> but values are not the expected ones: >> >> -bash-3.00$ ./odbc-integer-test >> >> Connecting to DSN=backenddb;uid=foo;pwd=bar >> Column 1. Name: MYID, Type: 8, Precision: 15, Scale: 0, TypeName: DOUBLE >> PRECISION >> Column 2. Name: MYINT, Type: 8, Precision: 15, Scale: 0, TypeName: >> DOUBLE PRECISION >> Id: 2176768, Value: 2176704 >> Id: 2147483647, Value: 2147483647 >> Id: 2147483647, Value: 2147483647 >> Id: 2147483647, Value: 2147483647 >> Id: 2147483647, Value: 2147483647 >> Id: 2147483647, Value: 2147483647 >> Id: 2147483647, Value: 2147483647 >> Id: 2147483647, Value: 2147483647 >> Id: 2147483647, Value: 2147483647 >> Id: 2147483647, Value: 2147483647 >> Finished >> >> The problems seems to be related with setInt in: >> >> static void insertValues(Connection *conn) >> throw (SQLException) >> { >> auto_ptr<PreparedStatement> stmt(conn->prepareStatement( >> "insert into " + s_tableName >> + "(myid, myint) values(?,?)")); >> for (int i = 0; i < 10; ++i) { >> stmt->setInt(1, i); >> stmt->setInt(2, i); >> stmt->executeUpdate(); >> } >> conn->commit(); >> } >> >> Digging a little into the code, it seems to me that for setInt, a >> SQLINTEGER wide buffer is used. This is mapping to a int, that in >> Solaris 64 bits is 4 bytes wide. I think that perhaps the driver is >> expecting an 8 bytes wide integer for this method, and that could be the >> reason for these weirds values being inserted. A query directly using >> the oracle sqlplus client, gives: >> >> SQL> select myid, myint from test_odbc_integer; >> >> MYID MYINT >> ---------- ---------- >> 2176768 2176704 >> 4297144064 4297144000 >> 8592111360 8592111296 >> 1.2887E+10 1.2887E+10 >> 1.7182E+10 1.7182E+10 >> 2.1477E+10 2.1477E+10 >> 2.5772E+10 2.5772E+10 >> 3.0067E+10 3.0067E+10 >> 3.4362E+10 3.4362E+10 >> 3.8657E+10 3.8657E+10 >> >> 10 rows selected. >> >> >> So, it seems data fetching works consistently, but not insertion. >> >> As a workaround, replacing those getInt method calls by getDouble ones, >> seems to work: >> >> -bash-3.00$ ./odbc-integer-test >> >> Connecting to DSN=backenddb;uid=foo;pwd=bar >> Column 1. Name: MYID, Type: 8, Precision: 15, Scale: 0, TypeName: DOUBLE >> PRECISION >> Column 2. Name: MYINT, Type: 8, Precision: 15, Scale: 0, TypeName: >> DOUBLE PRECISION >> Id: 0, Value: 0 >> Id: 1, Value: 1 >> Id: 2, Value: 2 >> Id: 3, Value: 3 >> Id: 4, Value: 4 >> Id: 5, Value: 5 >> Id: 6, Value: 6 >> Id: 7, Value: 7 >> Id: 8, Value: 8 >> Id: 9, Value: 9 >> Finished >> >> It seems to me that the problem could be located in what is fed to the >> SQLBindParameter ODBC function. The bufferSize is passed in, but perhaps >> the oracle driver is not honouring that value. I will try to write some >> ODBC pure test to see how the buffer should be specified to be >> interpreted correctly. I'm afraid this problem can only be reproduced in >> 64 bit environments. >> >> Best regards. >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Return on Information: >> Google Enterprise Search pays you back >> Get the facts. >> http://p.sf.net/sfu/google-dev2dev >> _______________________________________________ >> libodbcxx-devel mailing list >> lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel >> > > > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > libodbcxx-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAksnW+oACgkQ74ci1S6/F5+dkwCgoLasUnKpjBsmssGCwoMNqEF2 B2UAnA+EDwnuv2X+vXluj5FQN6wbQQtu =j/Kj -----END PGP SIGNATURE----- |
|
From: Manuel T. <mt...@ti...> - 2009-12-14 16:15:40
|
Hello. Some more data into the issue.
Testing with the following table:
create table integer_test(myint number not null);
I created a ODBC program trying to insert a value into the table, and
showing it later. I will omit all the tedious ODBC code, but the effect
with odbc++ and integer types can be reproduced. This code:
SQLINTEGER intValue = 55;
r = SQLBindParameter(hstmt,
(SQLUSMALLINT) 1,
(SQLSMALLINT) SQL_PARAM_INPUT,
(SQLSMALLINT) SQL_C_LONG,
(SQLSMALLINT) SQL_INTEGER,
0, 0, &intValue, 0, 0);
to execute the sentence
INSERT INTO INTEGER_TEST(MYINT) VALUES (?)
Is inserting 236223201280.
But changing the intValue type to long (8 bytes in solaris 64 bits) the
value is inserted correctly as 55.
So, it seems to me that the Oracle driver expects SQL_C_LONG values into
a 8 bytes buffer. Unfortunately, I don't know if this is the expected
behaviour, or how to change the odbc++ code to cleanly honour this need.
Probably, drivers should honour SQLINTEGER size for these values, but
Oracle is expecting a long here. The first question that arises is:
What size should a SQLINTEGER have in a 64 bits platform?
Have all 64 bit platforms the same definitions than Solaris for int and
long (4 and 8 bytes respectively) ?
Best regards.
Manuel Teira escribió:
> Hello again.
> Unfortunately, my last tests with the new driver were not creating
> entries into the table (I commented out the creation, deletion and fill
> of the table values to focus on data fetching).
> Once I've checked with the whole program again, I've found that I've got
> a problem with insertions, it seems to me that it is related with data
> wide expected by the oracle driver or something so:
>
> -bash-3.00$ ./odbc-integer-test
>
> Connecting to DSN=backenddb;uid=foo;pwd=bar
> Error performing tests: Error executing "insert into
> TEST_ODBC_INTEGER(myid, myint) values(?,?)":
> [Oracle][ODBC][Ora]ORA-01438: value larger than specified precision
> allowed for this column
>
> Finished.
>
> This problem arises while trying to fill the MYINT column, defined as
> NUMBER(5). If precision is not specified, the program runs correctly,
> but values are not the expected ones:
>
> -bash-3.00$ ./odbc-integer-test
>
> Connecting to DSN=backenddb;uid=foo;pwd=bar
> Column 1. Name: MYID, Type: 8, Precision: 15, Scale: 0, TypeName: DOUBLE
> PRECISION
> Column 2. Name: MYINT, Type: 8, Precision: 15, Scale: 0, TypeName:
> DOUBLE PRECISION
> Id: 2176768, Value: 2176704
> Id: 2147483647, Value: 2147483647
> Id: 2147483647, Value: 2147483647
> Id: 2147483647, Value: 2147483647
> Id: 2147483647, Value: 2147483647
> Id: 2147483647, Value: 2147483647
> Id: 2147483647, Value: 2147483647
> Id: 2147483647, Value: 2147483647
> Id: 2147483647, Value: 2147483647
> Id: 2147483647, Value: 2147483647
> Finished
>
> The problems seems to be related with setInt in:
>
> static void insertValues(Connection *conn)
> throw (SQLException)
> {
> auto_ptr<PreparedStatement> stmt(conn->prepareStatement(
> "insert into " + s_tableName
> + "(myid, myint) values(?,?)"));
> for (int i = 0; i < 10; ++i) {
> stmt->setInt(1, i);
> stmt->setInt(2, i);
> stmt->executeUpdate();
> }
> conn->commit();
> }
>
> Digging a little into the code, it seems to me that for setInt, a
> SQLINTEGER wide buffer is used. This is mapping to a int, that in
> Solaris 64 bits is 4 bytes wide. I think that perhaps the driver is
> expecting an 8 bytes wide integer for this method, and that could be the
> reason for these weirds values being inserted. A query directly using
> the oracle sqlplus client, gives:
>
> SQL> select myid, myint from test_odbc_integer;
>
> MYID MYINT
> ---------- ----------
> 2176768 2176704
> 4297144064 4297144000
> 8592111360 8592111296
> 1.2887E+10 1.2887E+10
> 1.7182E+10 1.7182E+10
> 2.1477E+10 2.1477E+10
> 2.5772E+10 2.5772E+10
> 3.0067E+10 3.0067E+10
> 3.4362E+10 3.4362E+10
> 3.8657E+10 3.8657E+10
>
> 10 rows selected.
>
>
> So, it seems data fetching works consistently, but not insertion.
>
> As a workaround, replacing those getInt method calls by getDouble ones,
> seems to work:
>
> -bash-3.00$ ./odbc-integer-test
>
> Connecting to DSN=backenddb;uid=foo;pwd=bar
> Column 1. Name: MYID, Type: 8, Precision: 15, Scale: 0, TypeName: DOUBLE
> PRECISION
> Column 2. Name: MYINT, Type: 8, Precision: 15, Scale: 0, TypeName:
> DOUBLE PRECISION
> Id: 0, Value: 0
> Id: 1, Value: 1
> Id: 2, Value: 2
> Id: 3, Value: 3
> Id: 4, Value: 4
> Id: 5, Value: 5
> Id: 6, Value: 6
> Id: 7, Value: 7
> Id: 8, Value: 8
> Id: 9, Value: 9
> Finished
>
> It seems to me that the problem could be located in what is fed to the
> SQLBindParameter ODBC function. The bufferSize is passed in, but perhaps
> the oracle driver is not honouring that value. I will try to write some
> ODBC pure test to see how the buffer should be specified to be
> interpreted correctly. I'm afraid this problem can only be reproduced in
> 64 bit environments.
>
> Best regards.
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> libodbcxx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel
>
|
|
From: Manuel T. <mt...@ti...> - 2009-12-14 14:04:59
|
Hello again.
Unfortunately, my last tests with the new driver were not creating
entries into the table (I commented out the creation, deletion and fill
of the table values to focus on data fetching).
Once I've checked with the whole program again, I've found that I've got
a problem with insertions, it seems to me that it is related with data
wide expected by the oracle driver or something so:
-bash-3.00$ ./odbc-integer-test
Connecting to DSN=backenddb;uid=foo;pwd=bar
Error performing tests: Error executing "insert into
TEST_ODBC_INTEGER(myid, myint) values(?,?)":
[Oracle][ODBC][Ora]ORA-01438: value larger than specified precision
allowed for this column
Finished.
This problem arises while trying to fill the MYINT column, defined as
NUMBER(5). If precision is not specified, the program runs correctly,
but values are not the expected ones:
-bash-3.00$ ./odbc-integer-test
Connecting to DSN=backenddb;uid=foo;pwd=bar
Column 1. Name: MYID, Type: 8, Precision: 15, Scale: 0, TypeName: DOUBLE
PRECISION
Column 2. Name: MYINT, Type: 8, Precision: 15, Scale: 0, TypeName:
DOUBLE PRECISION
Id: 2176768, Value: 2176704
Id: 2147483647, Value: 2147483647
Id: 2147483647, Value: 2147483647
Id: 2147483647, Value: 2147483647
Id: 2147483647, Value: 2147483647
Id: 2147483647, Value: 2147483647
Id: 2147483647, Value: 2147483647
Id: 2147483647, Value: 2147483647
Id: 2147483647, Value: 2147483647
Id: 2147483647, Value: 2147483647
Finished
The problems seems to be related with setInt in:
static void insertValues(Connection *conn)
throw (SQLException)
{
auto_ptr<PreparedStatement> stmt(conn->prepareStatement(
"insert into " + s_tableName
+ "(myid, myint) values(?,?)"));
for (int i = 0; i < 10; ++i) {
stmt->setInt(1, i);
stmt->setInt(2, i);
stmt->executeUpdate();
}
conn->commit();
}
Digging a little into the code, it seems to me that for setInt, a
SQLINTEGER wide buffer is used. This is mapping to a int, that in
Solaris 64 bits is 4 bytes wide. I think that perhaps the driver is
expecting an 8 bytes wide integer for this method, and that could be the
reason for these weirds values being inserted. A query directly using
the oracle sqlplus client, gives:
SQL> select myid, myint from test_odbc_integer;
MYID MYINT
---------- ----------
2176768 2176704
4297144064 4297144000
8592111360 8592111296
1.2887E+10 1.2887E+10
1.7182E+10 1.7182E+10
2.1477E+10 2.1477E+10
2.5772E+10 2.5772E+10
3.0067E+10 3.0067E+10
3.4362E+10 3.4362E+10
3.8657E+10 3.8657E+10
10 rows selected.
So, it seems data fetching works consistently, but not insertion.
As a workaround, replacing those getInt method calls by getDouble ones,
seems to work:
-bash-3.00$ ./odbc-integer-test
Connecting to DSN=backenddb;uid=foo;pwd=bar
Column 1. Name: MYID, Type: 8, Precision: 15, Scale: 0, TypeName: DOUBLE
PRECISION
Column 2. Name: MYINT, Type: 8, Precision: 15, Scale: 0, TypeName:
DOUBLE PRECISION
Id: 0, Value: 0
Id: 1, Value: 1
Id: 2, Value: 2
Id: 3, Value: 3
Id: 4, Value: 4
Id: 5, Value: 5
Id: 6, Value: 6
Id: 7, Value: 7
Id: 8, Value: 8
Id: 9, Value: 9
Finished
It seems to me that the problem could be located in what is fed to the
SQLBindParameter ODBC function. The bufferSize is passed in, but perhaps
the oracle driver is not honouring that value. I will try to write some
ODBC pure test to see how the buffer should be specified to be
interpreted correctly. I'm afraid this problem can only be reproduced in
64 bit environments.
Best regards.
|
|
From: Manuel T. <mt...@ti...> - 2009-12-14 07:57:54
|
Hello, Mark, Thanks for looking into this issue. Friday late I tried with the 10.2.0.4 Oracle ODBC driver. In my first attempt, I got SIGSEGV in ::odbc::ResultSetMetaData::_getNumericAttribute. However, a pure ODBC test program didn't show that behaviour. I found the problem was my odbc++ library being linked against an old version of unixODBC, where SQLLEN was 4 bytes wide instead of 8. Recompiling libodbc++ against an updated unixODBC version got me a working scenario, getting the same results that in your mysql tests. It seems that the change of SQLLEN from 4 to 8 bytes was causing more grief, since my ODBC level tests against the 10.2.0.3 were not working since I was using 8 byte SQLLEN against the 4 byte expected by the 10.2.0.3 driver. Best regards. Mark Kromis escribió: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Greetings, > > I tried the same code (table creation was slightly different) on MySql on Windows and it did not show the problem. I am currently looking in to the issue. > > Have you make any progress in this matter? > > It may have to do with oracle if it is not showing on other odbc drivers. Do they have an updated odbc driver? > > Connecting to DSN=mysql-test;uid=root;pwd=xxxxxx > Column 1. Name: myid, Type: 8, Precision: 15, Scale: 0, TypeName: double > Column 2. Name: myint, Type: 3, Precision: 5, Scale: 0, TypeName: decimal > Id: 0, Value: 0 > Id: 1, Value: 1 > Id: 2, Value: 2 > Id: 3, Value: 3 > Id: 4, Value: 4 > Id: 5, Value: 5 > Id: 6, Value: 6 > Id: 7, Value: 7 > Id: 8, Value: 8 > Id: 9, Value: 9 > Finished > > > On 2009/12/04, at 9:17, Manuel Teira wrote: > > >> Hello. This is my first post to the list. First of all I would like to >> thank you for the useful work this library represents for me. >> >> I'm using libodbc++-0.2.4pre4 combined with unixODBC-2.2.14 and a Oracle >> ODBC official driver 10.2.0.3,on a Solaris 10 machine, all this compiled >> with Sun Studio 12, to generate 64 bit objects. >> >> The problem arises with NUMBER fields in the database. I'm not sure at >> what level this problem is located, but I would like to know your >> opinion. Everything seems related with the metadata for NUMBER with >> precission. I mean, a NUMBER field is working as expected (so far) but a >> NUMBER(N) is not. >> >> I've created a simple test program, that creates a table, inserts 10 >> rows and tries to recover them later, showing the error. >> I suspect that the problem is not located in libodbc++, and perhaps >> neither in unixODBC, for I suppose that the metadata is provided >> directly by the ODBC driver in use. >> >> This is the result of the execution: >> >> -bash-3.00$ ./odbc-integer-test 'DSN=backend;uid=foo;pwd=bar' >> >> Connecting to DSN=backend;uid=foo;pwd=bar >> Column 1. Name: MYID, Type: 8, Precision: 15, Scale: 0, TypeName: DOUBLE >> PRECISION >> Column 2. Name: MYINT, Type: 3, Precision: 5, Scale: 0, TypeName: DECIMAL >> Id: 0, Value: 0 >> Id: 1, Value: 0 >> Id: 2, Value: 0 >> Id: 3, Value: 0 >> Id: 4, Value: 0 >> Id: 5, Value: 0 >> Id: 6, Value: 0 >> Id: 7, Value: 0 >> Id: 8, Value: 0 >> Id: 9, Value: 0 >> Finished >> >> As you can see, the first column is a NUMBER, the second one a >> NUMBER(5). The source of evil seems to be the metadata returned by the >> second column, as DECIMAL with precission 5. I've tested that data >> inside the table is right, disabling deletion in the program and >> accessing with Oracle sqlplus. >> >> I'm attaching the source code, any comment or idea will be welcomed. >> >> >> Best regards. >> >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (Darwin) > > iEYEARECAAYFAkskvhoACgkQ74ci1S6/F5/pPACgnSpaIc9bRx6NDcY28U4lgaix > 8qkAn2k9ahdeTeGKnGN4Id0iFUJNUyA2 > =WnM0 > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > libodbcxx-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel > |
|
From: Mark K. <gre...@ma...> - 2009-12-13 10:13:18
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings,
I tried the same code (table creation was slightly different) on MySql on Windows and it did not show the problem. I am currently looking in to the issue.
Have you make any progress in this matter?
It may have to do with oracle if it is not showing on other odbc drivers. Do they have an updated odbc driver?
Connecting to DSN=mysql-test;uid=root;pwd=xxxxxx
Column 1. Name: myid, Type: 8, Precision: 15, Scale: 0, TypeName: double
Column 2. Name: myint, Type: 3, Precision: 5, Scale: 0, TypeName: decimal
Id: 0, Value: 0
Id: 1, Value: 1
Id: 2, Value: 2
Id: 3, Value: 3
Id: 4, Value: 4
Id: 5, Value: 5
Id: 6, Value: 6
Id: 7, Value: 7
Id: 8, Value: 8
Id: 9, Value: 9
Finished
On 2009/12/04, at 9:17, Manuel Teira wrote:
> Hello. This is my first post to the list. First of all I would like to
> thank you for the useful work this library represents for me.
>
> I'm using libodbc++-0.2.4pre4 combined with unixODBC-2.2.14 and a Oracle
> ODBC official driver 10.2.0.3,on a Solaris 10 machine, all this compiled
> with Sun Studio 12, to generate 64 bit objects.
>
> The problem arises with NUMBER fields in the database. I'm not sure at
> what level this problem is located, but I would like to know your
> opinion. Everything seems related with the metadata for NUMBER with
> precission. I mean, a NUMBER field is working as expected (so far) but a
> NUMBER(N) is not.
>
> I've created a simple test program, that creates a table, inserts 10
> rows and tries to recover them later, showing the error.
> I suspect that the problem is not located in libodbc++, and perhaps
> neither in unixODBC, for I suppose that the metadata is provided
> directly by the ODBC driver in use.
>
> This is the result of the execution:
>
> -bash-3.00$ ./odbc-integer-test 'DSN=backend;uid=foo;pwd=bar'
>
> Connecting to DSN=backend;uid=foo;pwd=bar
> Column 1. Name: MYID, Type: 8, Precision: 15, Scale: 0, TypeName: DOUBLE
> PRECISION
> Column 2. Name: MYINT, Type: 3, Precision: 5, Scale: 0, TypeName: DECIMAL
> Id: 0, Value: 0
> Id: 1, Value: 0
> Id: 2, Value: 0
> Id: 3, Value: 0
> Id: 4, Value: 0
> Id: 5, Value: 0
> Id: 6, Value: 0
> Id: 7, Value: 0
> Id: 8, Value: 0
> Id: 9, Value: 0
> Finished
>
> As you can see, the first column is a NUMBER, the second one a
> NUMBER(5). The source of evil seems to be the metadata returned by the
> second column, as DECIMAL with precission 5. I've tested that data
> inside the table is right, disabling deletion in the program and
> accessing with Oracle sqlplus.
>
> I'm attaching the source code, any comment or idea will be welcomed.
>
>
> Best regards.
>
>
> #include <iostream>
> #include <iostream>
> #include <strstream>
> #include <sstream>
> #include <fstream>
>
> #include <odbc++/drivermanager.h>
> #include <odbc++/connection.h>
> #include <odbc++/resultset.h>
> #include <odbc++/resultsetmetadata.h>
> #include <odbc++/preparedstatement.h>
>
> using namespace std;
> using namespace odbc;
>
> static string s_uri;
>
> static string s_tableName("TEST_ODBC_INTEGER");
>
> static void createTables(Connection *conn)
> throw (SQLException)
> {
> auto_ptr<Statement> stmt = auto_ptr<Statement>(conn->createStatement());
> stmt->executeUpdate("create table " + s_tableName +
>
> auto_ptr<Statement> stmt = auto_ptr<Statement>(conn->createStatement());
> stmt->executeUpdate("create table " + s_tableName +
> " (myid number not null primary key,"
> " myint number(5) not null)");
> }
>
> static void deleteTables(Connection *conn)
> throw (SQLException)
> {
> auto_ptr<Statement> stmt = auto_ptr<Statement>(conn->createStatement());
> stmt->executeUpdate("drop table " + s_tableName);
> }
>
> static void insertValues(Connection *conn)
> throw (SQLException)
> {
> auto_ptr<PreparedStatement> stmt =
> auto_ptr<PreparedStatement>(conn->prepareStatement(
> "insert into " + s_tableName
> + "(myid, myint) values(?,?)"));
> for (int i = 0; i < 10; ++i) {
> stmt->setInt(1, i);
> stmt->setInt(2, i);
> stmt->executeUpdate();
> }
> conn->commit();
> }
>
> static void queryValues(Connection *conn)
> throw (SQLException)
> {
> auto_ptr<PreparedStatement> stmt =
> auto_ptr<PreparedStatement>(conn->prepareStatement(
> "select myid, myint from " +
> s_tableName));
> auto_ptr<ResultSet> rs = auto_ptr<ResultSet>(stmt->executeQuery());
> ResultSetMetaData *md = rs->getMetaData();
> for (int i = 1; i <= md->getColumnCount(); ++i) {
> cout << "Column " << i << ". Name: " << md->getColumnName(i)
> << ", Type: " << md->getColumnType(i)
> << ", Precision: " << md->getPrecision(i)
> << ", Scale: " << md->getScale(i)
> << ", TypeName: " << md->getColumnTypeName(i)
> << endl;
> }
> while (rs->next()) {
> cout << "Id: " << rs->getInt(1) << ", Value: " << rs->getInt(2) <<
> endl;
> }
> }
>
> int main(int argc, char *argv[])
> {
> if (argc < 2) {
> s_uri = "DSN=backend;uid=foo;pwd=bar";
> } else {
> s_uri = argv[1];
> }
>
> try {
> cout << endl << "Connecting to " << s_uri << endl;
>
> auto_ptr<Connection> conn =
> auto_ptr<Connection>(DriverManager::getConnection(s_uri));
> conn->setAutoCommit(false);
> createTables(conn.get());
> insertValues(conn.get());
> queryValues(conn.get());
> deleteTables(conn.get());
> } catch (SQLException &sqle) {
> cout << "Error performing tests: " << sqle.getMessage() << endl;
> } catch (...) {
> cout << "Unexpected error" << endl;
> }
> cout << "Finished" << endl;
> }
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> libodbcxx-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (Darwin)
iEYEARECAAYFAkskvhoACgkQ74ci1S6/F5/pPACgnSpaIc9bRx6NDcY28U4lgaix
8qkAn2k9ahdeTeGKnGN4Id0iFUJNUyA2
=WnM0
-----END PGP SIGNATURE-----
|
|
From: Manuel T. <mt...@ti...> - 2009-12-04 14:17:15
|
Hello. This is my first post to the list. First of all I would like to
thank you for the useful work this library represents for me.
I'm using libodbc++-0.2.4pre4 combined with unixODBC-2.2.14 and a Oracle
ODBC official driver 10.2.0.3,on a Solaris 10 machine, all this compiled
with Sun Studio 12, to generate 64 bit objects.
The problem arises with NUMBER fields in the database. I'm not sure at
what level this problem is located, but I would like to know your
opinion. Everything seems related with the metadata for NUMBER with
precission. I mean, a NUMBER field is working as expected (so far) but a
NUMBER(N) is not.
I've created a simple test program, that creates a table, inserts 10
rows and tries to recover them later, showing the error.
I suspect that the problem is not located in libodbc++, and perhaps
neither in unixODBC, for I suppose that the metadata is provided
directly by the ODBC driver in use.
This is the result of the execution:
-bash-3.00$ ./odbc-integer-test 'DSN=backend;uid=foo;pwd=bar'
Connecting to DSN=backend;uid=foo;pwd=bar
Column 1. Name: MYID, Type: 8, Precision: 15, Scale: 0, TypeName: DOUBLE
PRECISION
Column 2. Name: MYINT, Type: 3, Precision: 5, Scale: 0, TypeName: DECIMAL
Id: 0, Value: 0
Id: 1, Value: 0
Id: 2, Value: 0
Id: 3, Value: 0
Id: 4, Value: 0
Id: 5, Value: 0
Id: 6, Value: 0
Id: 7, Value: 0
Id: 8, Value: 0
Id: 9, Value: 0
Finished
As you can see, the first column is a NUMBER, the second one a
NUMBER(5). The source of evil seems to be the metadata returned by the
second column, as DECIMAL with precission 5. I've tested that data
inside the table is right, disabling deletion in the program and
accessing with Oracle sqlplus.
I'm attaching the source code, any comment or idea will be welcomed.
Best regards.
#include <iostream>
#include <iostream>
#include <strstream>
#include <sstream>
#include <fstream>
#include <odbc++/drivermanager.h>
#include <odbc++/connection.h>
#include <odbc++/resultset.h>
#include <odbc++/resultsetmetadata.h>
#include <odbc++/preparedstatement.h>
using namespace std;
using namespace odbc;
static string s_uri;
static string s_tableName("TEST_ODBC_INTEGER");
static void createTables(Connection *conn)
throw (SQLException)
{
auto_ptr<Statement> stmt = auto_ptr<Statement>(conn->createStatement());
stmt->executeUpdate("create table " + s_tableName +
auto_ptr<Statement> stmt = auto_ptr<Statement>(conn->createStatement());
stmt->executeUpdate("create table " + s_tableName +
" (myid number not null primary key,"
" myint number(5) not null)");
}
static void deleteTables(Connection *conn)
throw (SQLException)
{
auto_ptr<Statement> stmt = auto_ptr<Statement>(conn->createStatement());
stmt->executeUpdate("drop table " + s_tableName);
}
static void insertValues(Connection *conn)
throw (SQLException)
{
auto_ptr<PreparedStatement> stmt =
auto_ptr<PreparedStatement>(conn->prepareStatement(
"insert into " + s_tableName
+ "(myid, myint) values(?,?)"));
for (int i = 0; i < 10; ++i) {
stmt->setInt(1, i);
stmt->setInt(2, i);
stmt->executeUpdate();
}
conn->commit();
}
static void queryValues(Connection *conn)
throw (SQLException)
{
auto_ptr<PreparedStatement> stmt =
auto_ptr<PreparedStatement>(conn->prepareStatement(
"select myid, myint from " +
s_tableName));
auto_ptr<ResultSet> rs = auto_ptr<ResultSet>(stmt->executeQuery());
ResultSetMetaData *md = rs->getMetaData();
for (int i = 1; i <= md->getColumnCount(); ++i) {
cout << "Column " << i << ". Name: " << md->getColumnName(i)
<< ", Type: " << md->getColumnType(i)
<< ", Precision: " << md->getPrecision(i)
<< ", Scale: " << md->getScale(i)
<< ", TypeName: " << md->getColumnTypeName(i)
<< endl;
}
while (rs->next()) {
cout << "Id: " << rs->getInt(1) << ", Value: " << rs->getInt(2) <<
endl;
}
}
int main(int argc, char *argv[])
{
if (argc < 2) {
s_uri = "DSN=backend;uid=foo;pwd=bar";
} else {
s_uri = argv[1];
}
try {
cout << endl << "Connecting to " << s_uri << endl;
auto_ptr<Connection> conn =
auto_ptr<Connection>(DriverManager::getConnection(s_uri));
conn->setAutoCommit(false);
createTables(conn.get());
insertValues(conn.get());
queryValues(conn.get());
deleteTables(conn.get());
} catch (SQLException &sqle) {
cout << "Error performing tests: " << sqle.getMessage() << endl;
} catch (...) {
cout << "Unexpected error" << endl;
}
cout << "Finished" << endl;
}
|
|
From: Pete <pe...@ka...> - 2009-10-09 21:14:07
|
Hi JR, Here is a good summary of c++ error handling in ctors(): http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.2 Pay particular attention to 17.2 and 17.4. IMHO, if underflow() does throw and this causes a problem elsewhere, it is the callee that doesn't deal appropriately with the exception. I've never noticed that problem myself and my application works frequently with streamed data. Pete > -----Original Message----- > From: JR Andreassen [mailto:ja...@io...] > Sent: Saturday, 10 October 2009 1:51 a.m. > To: libodbc++ development mailing list > Subject: Re: [libodbcxx-devel] Commit 150 > > Hi... > I don't remember exactly.... > Probably for consistency.... > Let me check... > I checked our VCS... All it said was throw in > constructor....That was helpful. > > The issue was, if I remember correctly, that there was a > case when the "underflow" was called in the constructor of > "DataStreamBuf" it sometimes threw an exception(Don't remember why). > The problem was that it left the object partially initialized > and therefore subsequent operations caused problems. > > So, if I read your question correctly, "Why is it bad to > throw in ctor?".. > In this case, because it left the object partially > initialized and therefore invalid. > Does that answer your question ??? > JR. > > > Hi JR, > > > > I saw you introduced and used the macro > > THROWING_SHIT_IN_THE_CONSTRUCTOR_IS_A_BAD_IDEA_MAN, but I don't > > understand why? In dtors() yes, but ctors()? > > > > Pete > > > > > > > >> -----Original Message----- > >> From: Mark Kromis [mailto:gre...@ma...] > >> Sent: Tuesday, 29 September 2009 9:59 p.m. > >> To: libodbc++ development mailing list > >> Subject: Re: [libodbcxx-devel] Commit 150 > >> > >> > >> On Sep 29, 2009, at 4:10 AM, Pete wrote: > >> > > > -------------------------------------------------------------- > ---------------- > Come build with us! The BlackBerry(R) Developer Conference in > SF, CA is the only developer event you need to attend this > year. Jumpstart your developing skills, take BlackBerry > mobile applications to market and stay ahead of the curve. > Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > libodbcxx-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel > |
|
From: JR A. <ja...@io...> - 2009-10-09 12:52:21
|
Hi...
I don't remember exactly....
Probably for consistency....
Let me check...
I checked our VCS... All it said was throw in constructor....That was
helpful.
The issue was, if I remember correctly, that there was a case when the
"underflow" was called in the constructor
of "DataStreamBuf" it sometimes threw an exception(Don't remember why).
The problem was that it left the object partially initialized and
therefore subsequent operations caused problems.
So, if I read your question correctly, "Why is it bad to throw in ctor?"..
In this case, because it left the object partially initialized and
therefore invalid.
Does that answer your question ???
JR.
> Hi JR,
>
> I saw you introduced and used the macro
> THROWING_SHIT_IN_THE_CONSTRUCTOR_IS_A_BAD_IDEA_MAN, but I don't understand
> why? In dtors() yes, but ctors()?
>
> Pete
>
>
>
>> -----Original Message-----
>> From: Mark Kromis [mailto:gre...@ma...]
>> Sent: Tuesday, 29 September 2009 9:59 p.m.
>> To: libodbc++ development mailing list
>> Subject: Re: [libodbcxx-devel] Commit 150
>>
>>
>> On Sep 29, 2009, at 4:10 AM, Pete wrote:
>>
|
|
From: Pete <pe...@ka...> - 2009-10-09 10:41:52
|
I made these changes to SVN: Re-introduced some changes which were accidentally undone in revisions 133. Also changed some other trivial changes. The changes ensure that strings longer than 255 characters and streams can be added via parameters to prepared statements. Attached is a small test program I wrote a long time back to insert and extract blobs. I'd love to turn it into a unit test that we could include with distros. The sample contains a section with constants you need to configure to test blobs. One of the things that I have not managed to test yet is adding and retrieving files with a size which is a multiple of GETDATA_CHUNK_SIZE (this is defined as 4*1024). This used to be a problem. Pete |
|
From: Pete <pe...@ka...> - 2009-10-09 04:36:11
|
Hi JR, I saw you introduced and used the macro THROWING_SHIT_IN_THE_CONSTRUCTOR_IS_A_BAD_IDEA_MAN, but I don't understand why? In dtors() yes, but ctors()? Pete > -----Original Message----- > From: Mark Kromis [mailto:gre...@ma...] > Sent: Tuesday, 29 September 2009 9:59 p.m. > To: libodbc++ development mailing list > Subject: Re: [libodbcxx-devel] Commit 150 > > > On Sep 29, 2009, at 4:10 AM, Pete wrote: > > > Firstly, well done Mark, thank you! > > > > I noticed some changes in preparedstatement.cpp from Revision 132 to > > 133 > > reintroduced previously fixed bugs with streams and long > strings. I'm > > worried there are other areas too. > > Summary of changes for reference > http://libodbcxx.svn.sourceforge.net/viewvc/libodbcxx?view=rev > &revision=133 > > Those changes was contributed by JR Anderson. > > > > > If I'm lucky I'll have a bit of time later this week to more > > thoroughly check the code. I'll post another message here > once I got > > around doing this. > > Thanks > > > > > As it stands, there will be issues with streamed parameters > as well as > > string substitutes exceeding 256 characters in length. > > Maybe this can be added to a unit test. > > > > > Pete > > > > > >> -----Original Message----- > >> From: Mark Kromis [mailto:gre...@ma...] > >> Sent: Tuesday, 8 September 2009 5:40 p.m. > >> To: libodbc++ development mailing list > >> Subject: [libodbcxx-devel] Commit 150 > >> > >> Added cmake build system for windows based systems. This in not > >> working on non windows system. This should make it easier > for people > >> to import into eclipse, vis studio or any other IDE they need. For > >> windows its a quick download from http://www.cmake.org/. > There is a > >> gui for running the script so it should not be much of an issue. > >> > >> QtSql++ updated to compile on 4.5, This is a beta, there > are probably > >> lots of bugs. Needs more testing. > >> > >> Regards, > >> Mark Kromis > >> > >> -------------------------------------------------------------- > >> ---------------- > >> Let Crystal Reports handle the reporting - Free Crystal > Reports 2008 > >> 30-Day trial. Simplify your report design, integration and > deployment > >> - and focus on what you do best, core application coding. Discover > >> what's new with Crystal Reports now. > http://p.sf.net/sfu/bobj-july > >> _______________________________________________ > >> libodbcxx-devel mailing list > >> lib...@li... > >> https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel > >> > > > > > > > ---------------------------------------------------------------------- > > -------- Come build with us! The BlackBerry® Developer > Conference > > in SF, CA is the only developer event you need to attend this year. > > Jumpstart your developing skills, take BlackBerry mobile > applications > > to market and stay ahead of the curve. Join us from > November 9-12, > > 2009. Register now! http://p.sf.net/sfu/devconf > > _______________________________________________ > > libodbcxx-devel mailing list > > lib...@li... > > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel > > > -------------------------------------------------------------- > ---------------- > Come build with us! The BlackBerry® Developer Conference > in SF, CA is the only developer event you need to attend this > year. Jumpstart your developing skills, take BlackBerry > mobile applications to market and stay ahead of the curve. > Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > libodbcxx-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel > |
|
From: Pete <pe...@ka...> - 2009-09-29 21:13:44
|
Yes, I realise these were JR's changes, but it's most likely my fault. I probably committed my changes to CVS after Sourceforge's move from CVS to SVN. Old habits die hard, eh? I'll compare the latest versions in CVS with what went into SVN hopefully this Friday. Pete > -----Original Message----- > From: Mark Kromis [mailto:gre...@ma...] > Sent: Tuesday, 29 September 2009 9:59 p.m. > To: libodbc++ development mailing list > Subject: Re: [libodbcxx-devel] Commit 150 > > > On Sep 29, 2009, at 4:10 AM, Pete wrote: > > > Firstly, well done Mark, thank you! > > > > I noticed some changes in preparedstatement.cpp from Revision 132 to > > 133 > > reintroduced previously fixed bugs with streams and long > strings. I'm > > worried there are other areas too. > > Summary of changes for reference > http://libodbcxx.svn.sourceforge.net/viewvc/libodbcxx?view=rev > &revision=133 > > Those changes was contributed by JR Anderson. > > > > > If I'm lucky I'll have a bit of time later this week to more > > thoroughly check the code. I'll post another message here > once I got > > around doing this. > > Thanks > > > > > As it stands, there will be issues with streamed parameters > as well as > > string substitutes exceeding 256 characters in length. > > Maybe this can be added to a unit test. > > > > > Pete > > > > > >> -----Original Message----- > >> From: Mark Kromis [mailto:gre...@ma...] > >> Sent: Tuesday, 8 September 2009 5:40 p.m. > >> To: libodbc++ development mailing list > >> Subject: [libodbcxx-devel] Commit 150 > >> > >> Added cmake build system for windows based systems. This in not > >> working on non windows system. This should make it easier > for people > >> to import into eclipse, vis studio or any other IDE they need. For > >> windows its a quick download from http://www.cmake.org/. > There is a > >> gui for running the script so it should not be much of an issue. > >> > >> QtSql++ updated to compile on 4.5, This is a beta, there > are probably > >> lots of bugs. Needs more testing. > >> > >> Regards, > >> Mark Kromis > >> > >> -------------------------------------------------------------- > >> ---------------- > >> Let Crystal Reports handle the reporting - Free Crystal > Reports 2008 > >> 30-Day trial. Simplify your report design, integration and > deployment > >> - and focus on what you do best, core application coding. Discover > >> what's new with Crystal Reports now. > http://p.sf.net/sfu/bobj-july > >> _______________________________________________ > >> libodbcxx-devel mailing list > >> lib...@li... > >> https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel > >> > > > > > > > ---------------------------------------------------------------------- > > -------- Come build with us! The BlackBerry® Developer > Conference > > in SF, CA is the only developer event you need to attend this year. > > Jumpstart your developing skills, take BlackBerry mobile > applications > > to market and stay ahead of the curve. Join us from > November 9-12, > > 2009. Register now! http://p.sf.net/sfu/devconf > > _______________________________________________ > > libodbcxx-devel mailing list > > lib...@li... > > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel > > > -------------------------------------------------------------- > ---------------- > Come build with us! The BlackBerry® Developer Conference > in SF, CA is the only developer event you need to attend this > year. Jumpstart your developing skills, take BlackBerry > mobile applications to market and stay ahead of the curve. > Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > libodbcxx-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libodbcxx-devel > |
14 messages has been excluded from this view by a project administrator.
