Scott Zhong | 6 Jun 20:36 2014

setting SQL_ATTR_ODBC_CURSORS attribute to SQL_CUR_USE_ODBC fails to open the libodbccr library on AIX

Hi,

 

    unixODBC 2.3.2 on AIX 6.1 after setting SQL_ATTR_ODBC_CURSORS attribute to SQL_CUR_USE_ODBC and then connecting to a data source (DB2 is used in this testcase) produces an error about unable to open cursor library.

 

Testcase snippet:

 

SQLULEN attr_cur = SQL_CUR_USE_ODBC;

SQLSetConnectAttr (hdbc, SQL_ATTR_ODBC_CURSORS, (SQLPOINTER)(SQLLEN)attr_cur, NULL);

SQLDriverConnect (hdbc, NULL, connStrIn, SQL_NTS, connStrOut, BUFFER_LEN, &connStrOutLen, SQL_DRIVER_NOPROMPT);

 

/>uname -srv

AIX 1 6

/>oslevel -s

6100-09-01-1341

/>xlC -qversion

IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72)

Version: 12.01.0000.0008

/>xlC -I$ODBC/include testcase_setconnectattr.cpp -L$ODBC/lib -lodbc -lpthread -liconv

/>./a.out QE197UTF dbtest1 zebco5

 

Using specified DSN : QE197UTF

setting SQL_ATTR_ODBC_CURSORS to "1"

DSN=QE197UTF;Uid=dbtest1;Pwd=zebco5

rc: -1

ERROR: 0:  01000 : [unixODBC][Driver Manager]Can't open cursor lib '/nfs/packages/mdx/aix/ppc32/databases/unixodbc/2.3.2/etc/libodbccr.so' : file not found

Error in Step 1 -- SQLDriverConnect failed

Exiting!!

 

copying "libodbccr.a" to "/nfs/packages/mdx/aix/ppc32/databases/unixodbc/2.3.2/etc/libodbccr.so" does NOT fix the issue.

_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Scott Zhong | 4 Jun 21:34 2014

Valgrind shows memory leak

Hi,

 

    Valgrind  3.8.1 shows a memory leak in unixODBC 2.3.2 after setting SQL_ATTR_ODBC_CURSORS attribute to SQL_CUR_USE_ODBC and then connecting to a data source.

 

Testcase snippet:

 

SQLULEN attr_cur = SQL_CUR_USE_ODBC;

SQLSetConnectAttr (hdbc, SQL_ATTR_ODBC_CURSORS, (SQLPOINTER)(SQLLEN)attr_cur, NULL);

SQLDriverConnect (hdbc, NULL, connStrIn, SQL_NTS, connStrOut, BUFFER_LEN, &connStrOutLen, SQL_DRIVER_NOPROMPT);

 

/>uname -srm

Linux 2.6.32-358.el6.x86_64 x86_64

/>cat /etc/redhat-release

Red Hat Enterprise Linux Server release 6.4 (Santiago)

/>g++ -g -I$ODBC/include testcase_unixodbc_leak.cpp -L$ODBC/lib -lodbc -lpthread

/>valgrind --leak-check=full --show-reachable=no --show-possibly-lost=no --track-origins=yes --num-callers=50 --gen-suppressions=all --xml=yes --xml-file=testcase.valgrind a.out

 

Valgrind leak entry:

 

<error>

  <unique>0xc1</unique>

  <tid>1</tid>

  <kind>Leak_DefinitelyLost</kind>

  <xwhat>

    <text>5,056 (64 direct, 4,992 indirect) bytes in 1 blocks are definitely lost in loss record 167 of 170</text>

    <leakedbytes>5056</leakedbytes>

    <leakedblocks>1</leakedblocks>

  </xwhat>

  <stack>

    <frame>

      <ip>0x4A069EE</ip>

      <obj>/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so</obj>

      <fn>malloc</fn>

      <dir>/builddir/build/BUILD/valgrind-3.8.1/coregrind/m_replacemalloc</dir>

      <file>vg_replace_malloc.c</file>

      <line>270</line>

    </frame>

    <frame>

      <ip>0x127A65E5</ip>

    </frame>

    <frame>

      <ip>0x4C206BD</ip>

      <obj>/amd/packages/mdx/redhat/databases/unixodbc/x86_64-gcc4.1.2/lib/libodbc.so.1.0.0</obj>

      <fn>__connect_part_two</fn>

    </frame>

    <frame>

      <ip>0x4C28F74</ip>

      <obj>/amd/packages/mdx/redhat/databases/unixodbc/x86_64-gcc4.1.2/lib/libodbc.so.1.0.0</obj>

      <fn>SQLDriverConnect</fn>

    </frame>

    <frame>

      <ip>0x400F70</ip>

      <obj>/amd/tmp/scottz/a.out</obj>

      <fn>main</fn>

      <dir>/nfs/tmp/scottz</dir>

      <file>testcase_unixodbc_leak.cpp</file>

      <line>208</line>

    </frame>

  </stack>

  <suppression>

    <sname>insert_a_suppression_name_here</sname>

    <skind>Memcheck:Leak</skind>

    <sframe> <fun>malloc</fun> </sframe>

    <sframe> <obj>*</obj> </sframe>

    <sframe> <fun>__connect_part_two</fun> </sframe>

    <sframe> <fun>SQLDriverConnect</fun> </sframe>

    <sframe> <fun>main</fun> </sframe>

    <rawtext>

<![CDATA[

{

   <insert_a_suppression_name_here>

   Memcheck:Leak

   fun:malloc

   obj:*

   fun:__connect_part_two

   fun:SQLDriverConnect

   fun:main

}

]]>

    </rawtext>

  </suppression>

</error>

 

Regards,

Scott Z.

_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
David Brown | 9 May 22:50 2014

Problems building from SVN

I am getting the following error when trying to build 2.3.3pre fetched from svn - suggestions?
 
make -f Makefile.svn
fails with:
 
*** Retrieving configure tests needed by configure.in
libtoolize: AC_CONFIG_MACRO_DIR([libltdl/m4]) conflicts with ACLOCAL_AMFLAGS=-I m4.
make: *** [svn] Error 1
 
Makefile.am:ACLOCAL_AMFLAGS=-I m4
 
I see that there are 2 m4 directories (./m4 and libltdl/m4) containing files of the same names, but with different contents - not sure if they are both used, or if one is obsolete. The files in libltdl/m4 are slightly larger, so if one is obsolete, I'm guessing it's ./m4.
 
Thanks
David Brown
StarQuest
 
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
FAU | 5 May 04:19 2014
Picon

SQLDataSourcesW() Buffer Lengths

Hello,

It seems to be that SQLDataSourcesW() takes the buffer lengths arguments
as number of bytes which should be number of characters.  See
https://support.microsoft.com/kb/294169 for clarification.

Regards
-Frank

_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev

David Brown | 2 May 03:31 2014

ANSI to Unicode mapping issues (resend)

(Pardon me if this is a duplicate - I tried sending it a few days ago from a 
different address, but it didn't appear to go through)

We have been building and shipping an older ANSI version of our ODBC driver
(StarSQL) in Unix/Linux environments. We recently ported our current Unicode
ODBC driver (which has been running on Windows for several years) to Linux,
and ran into some issues that appear to be related to the unixODBC Driver
Manager mappings from ANSI entry point to the driver's Unicode entry points
when an ANSI application invokes ODBC calls to a Unicode driver.

Has anyone else encountered any of these issues?  Thoughts on a solution?

We are using the 2.3.2 release.

Here is a list of the issues encountered by the developer of our driver:

1)      The Driver Manager does not map calls from an ANSI application's
call to SQLGet/SetStmtOption to a Unicode driver's SQLGet/SetStmtAttrW entry
points. It only does the mapping to SQLGet/SetStmtAttr for ANSI drivers. We
were able to work around this by adding SQLGet/SetStmtOption function entry
points in our driver, but we shouldn't have to do that.

2)      SQLSetDescField does not alter the length supplied by the
application ("buffer_length") when the field supplied is a string which
value gets converted to Unicode before being passed to the Unicode Driver.
In this particular Unicode ODBC API, the buffer_length should be a
byte-count, not a character-count. The implementation of SQLGetDescField in
the unixODBC driver manager does deal with this better and divides
string_length by sizeof(SQLWCHAR) before returning to the application. That
works better, but is too simplistic for multi-byte ANSI data (e.g. UTF-8)
See
#3.

3)      Conversions between Unicode and ANSI are almost universally assuming
that one byte of ANSI data will produce two bytes of Unicode data (when
sizeof(SQLWCHAR) is 2). The code needs to check the length of the resulting
string (ANSI or Unicode) whenever such a conversion occurs and then use the
resulting length when passing it on to the driver or calling application.
Functions like  the ANSI versions of  SQLPrepare and SQLExecDirect can't
just perform an ansi-to-unicode translation and then pass the application
supplied length to the Unicode driver.

Looking at the unixODBC code, it seems clear that we were exposed to similar
issues
with our old ANSI driver when called from a Unicode application.
Applications using parameter markers rather than string literals would be
less sensitive to the limitations of the current unixODBC driver manager
implementation since keywords and identifiers are less likely to contain
"problematic" characters , but it would seem important to address this none
the less.

Any suggestions would be appreciated.

Thanks
David Brown
StarQuest

_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev

Michael Jerris | 18 Apr 19:47 2014

patches fixing bugs in postgres 7.1 driver

Please see attached patches for memory leaks and a data truncation issue in the postgres driver.  Feedback
and inclusion appreciated.

Thanks
Mike

Attachment (postgres7.1.fixes.diff): application/octet-stream, 5625 bytes

_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Heikki Linnakangas | 24 Mar 20:37 2014

Handling malloc failure

Hi,

Many of the functions in __handles.c don't handle a NULL result from 
malloc/calloc properly. There are if-checks for it, but then they go 
ahead and reference the NULL pointer anyway. See attached patch.

- Heikki
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Tony Gelsy Sampaio | 19 Mar 16:08 2014
Picon

Mantenha contato comigo através do LinkedIn.

 
 
 
 
 
De Tony Gelsy Sampaio
 
Graduado em Ciência da Computação (UFMT) Especialista em Redes e Computação Distribuída (IFMT)
Cuiabá e Região, Brasil
 
 
 
 
 
 
 

Eu gostaria de adicioná-lo à minha rede profissional no LinkedIn.
-Tony Gelsy

 
 
 
 
 
 
 
Você está recebendo convites de conexão por e-mail. Cancelar inscrição
© 2014, LinkedIn Corporation. 2029 Stierlin Ct. Mountain View, CA 94043, EUA
 
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Daniel Kasak | 12 Mar 07:42 2014
Picon

Teradata and 'SQL_ERROR or SQL_SUCCESS_WITH_INFO but no error reporting API found'

Hi all.

I have to connect to multiple databases via ODBC, so I *assume* I have to use unixODBC ( and not, for example, Teradata's driver manager). The problem is that Teradata's ODBC drivers appear to be pretty bad. If I execute a statement that works, everything is fine. But if I execute something that raises an error, I get:

SQL_ERROR or SQL_SUCCESS_WITH_INFO but no error reporting API found

I've googled for a while and found other people with the same issue, but no solution. What's going on here? Am I correct in assuming that Teradata simply haven't implemented an error reporting API?

Dan
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
ZhengYabin | 1 Mar 02:29 2014
Picon

Issues when cross-compile the freetds using unixODBC

Hi,
        I’m recently using unixODBC and freetds to build a development environment for accessing a remote SQL Server on an arm-linux platform.
Things I’ve already done:
1.build x86 unixODBC with “./configure --prefix=/usr/local/unixODBC-x86”
2. cross-compile build unixODBC with “./configure --prefix=/usr/local/unixODBC-arm --host=arm-linux”

Then I tried to build freetds with unixODBC
3.build x86 freetds with “./configure --prefix=/usr/local/freetds-x86 --with-unixodbc=/usr/local/unixODBC-x86”, the process is good.
4. but when I tried to build arm edition with
“./configure --prefix=/usr/local/freetds-arm --with-unixodbc=/usr/local/unixODBC-arm --host=arm-linux”
it always genarated an error

./configure: line 16574: /usr/local/unixODBC-arm/bin/odbc_config: connot execute binary file
./configure: line 16575: /usr/local/unixODBC-arm/bin/odbc_config: connot execute binary file
configure: error: sql.h not found

It seems the configure script tried to execute the arm-linux edition odbc_config, it will definitely failed.
How to fix the problem to complete the cross-compile build?



发自 Windows 邮件

_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Jan Staněk | 18 Feb 10:17 2014
Picon

Manual pages for executables

Hello,
I have created manual pages for undocumented executables iusql (which is
added to isql man page and linked to it), dltest and odbc_config.

As an attachment, I send the man pages plus the patch to isql.1.

Best regards,
Jan

--

-- 
Jan Stanek - Red Hat Associate Developer Engineer - Databases Team
Attachment (dltest.1): application/x-troff-man, 912 bytes
Attachment (iusql.1): application/x-troff-man, 16 bytes
Attachment (odbc_config.1): application/x-troff-man, 2172 bytes
Attachment (unixODBC-isql.1.patch): text/x-patch, 687 bytes
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev

Gmane