xiaonan | 20 Nov 03:40 2014

A discussion about unixODBC programming model

Hi Nick,

	Now our project uses unixODBC like this:
	
	(1) Use connection pool:
	/usr/local/etc/odbcinst.ini
	[ODBC]
	Trace=No
	Pooling=Yes
	
	(2) When program initiates, allocate a global environment handle:
	SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &g_env_handle));
	
	(3) Encapsulate a SQL operation function:
	sql_func()
	{
		/* Allocate connection handle */
		SQLAllocHandle(SQL_HANDLE_DBC, g_env_handle, &conn_handle);
		/* Connect database */
		SQLConnect(conn_handle, ...);
		
		/* Allocate statement handle */
		SQLAllocHandle(SQL_HANDLE_STMT, conn_handle, &stmt_handle);
		/* Execute statement */
		SQLExecDirect(stmt_handle, ...);
		/* Free statement handle */
		SQLFreeHandle(SQL_HANDLE_STMT, stmt_handle);
		
		/* Disconnect database */
		SQLDisconnect(conn_handle);
(Continue reading)

xiaonan | 19 Nov 09:41 2014

Add the NULL pointer check in some functions

Hi Nick,

At the beginning of the __validate_stmt(), the function will check whether the statement is NULL or not:
int __validate_stmt( DMHSTMT statement )
{
#ifdef FAST_HANDLE_VALIDATE

if ( statement && *(( int * ) statement ) == HSTMT_MAGIC )
return 1;
else
return 0;

#else
......
#endif
}
So I think __validate_env(), __validate_dbc() and __validate_desc() should all add this protection. E.g.:
int __validate_env( DMHENV env )
{
#ifdef FAST_HANDLE_VALIDATE

if ( env && *(( int * ) env ) == HENV_MAGIC )
return 1;
else
return 0;
#else
......
#endif
}

Best Regards
Nan Xiao


_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
xiaonan | 18 Nov 07:09 2014

A question about config.h

Hi Nick,

I use unixODBC 2.3.2 released version. After calling "./configure", I see the following strings in config.h:

/* Define to the full name and version of this package. */
#define PACKAGE_STRING "unixODBC 2.3.2-pre"

/* Define to the version of this package. */
#define PACKAGE_VERSION "2.3.2-pre"

I think they should be:

/* Define to the full name and version of this package. */
#define PACKAGE_STRING "unixODBC 2.3.2"

/* Define to the version of this package. */
#define PACKAGE_VERSION "2.3.2"

Right? Thanks!

Best Regards
Nan Xiao


_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Chris Golledge | 21 Aug 02:12 2014
Picon

sizeof SQL_ATTR_TXN_ISOLATION value

The Microsoft definition for the value is "A 32-bit bitmask ...".  The unixODBC driver manager implements this value as an int (SQLINTEGER).  The size of the int type is platform dependent.  On little endian systems, it works out OK for my driver to write only the first 32 bits (at least if the variable is initialized), but on a 64-bit, big endian system, like AIX (and I think Solaris), the app reading the value as a 64-bit integer when the driver has written the value into the high order bytes does not work.

There is no mention per se of this attribute at http://www.unixodbc.org/doc/ODBC64.html or http://support.microsoft.com/kb/298678, so, you might say that since it was originally a 32-bit mask, and there is no mention of it, it should remain a 32-bit mask.   But, you can get there by going around the barn. TXN_ISOLATION has been around since ODBC 1.0, at which time it was set with SQLSetConnectOption, and there is the change in the table that

    SQLSetConnectOption
    SQLULEN Value

and SQLSetConnectOption maps to SQLSetConnectAttr.

Is there a better explanation for why this attribute value becomes 64-bits on AIX?  
(Being pedantic, if this logic is correct, I'm thinking it should be declared as an SQLULEN  instead of an SQLINTEGER in the DM code.)

Chris Golledge
IBM Software Group, Lenexa KS
Tel: (913) 599 7250

"Ah, because I have learned something since last week."  - Gandhi
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
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

Gmane