Heikki Linnakangas | 23 Jan 12:16 2015

Grab bag of typo fixes

Hi,

Attached is a patch with miscellaneous typo fixes, mostly in comments.

- Heikki
Attachment (typo-fixes-1.patch): text/x-diff, 13 KiB
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Jens Kallup | 17 Jan 17:04 2015
Picon

Re: MySQL properties (Nick Gorham)

Hello Nick,

I get working by setup the right library.
Give it programmers here, that have support for "dBase" odbc drivers?
It would be great if someone tell me, how to download.
The dBase driver should support the Level 7 format.

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

Jens Kallup | 16 Jan 23:32 2015
Picon

MySQL properties

Hello,

I am new in odbc, but i could compile the package 2.3.2.
Now, the problem is, I can not add new drivers to the list.
e.g.: when I try to use the tool ODBCCreateDataSooureQ4,
I get the error  "could not find setup property for (MySQL) in system 
information".
I have install mysql.
what can this be?

great waiting for response
Jens
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev

xiaonan | 25 Dec 04:15 2014

Memory leak in __SQLAllocHandle

Hi Nick,

Merry Xmas!
In the line 874 and 1051 of __SQLAllocHandle function(DriverManager/SQLAllocHandle.c), I think the __release_stmt( statement ) should be called, like this:
{
__release_stmt( statement );
*output_handle = SQL_NULL_HSTMT;
}
Else the memory will leak.
Best Regards
Nan Xiao


_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
xiaonan | 9 Dec 06:55 2014

An issue about SQLFreeStmt


Hi Nick,

Sorry for interrupting you!

Could you give some comments on this issue in stackoverflow.com? Thanks very much in advance!

Best Regards
Nan Xiao


_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
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);
		/* Free connection handle */
		SQLFreeHandle(SQL_HANDLE_DBC, conn_handle);
	}
	
	So all the SQL related operations will be executed through this sql_func.

	This encapsulate is easy and clear, but now I consider whether this will lead low efficiency. Because every SQL operation will allocate connection handle, connect database (although the connection pool is used), allocate statement handle, free handles, etc.
	
	So I consider whether I can do like this:
	(1) This is the same as now: still use connection pool.
	
	(2) When program initiates, except the global environment handle, I still allocate a connection handle pool:
	create_connection_handle_pool()
	{
		for (...)
		{
			/* Allocate connection handle */
			SQLAllocHandle(SQL_HANDLE_DBC, g_env_handle, &conn_handle);
			/* Connect database */
			SQLConnect(conn_handle, ...);
		}
	}
	
	(3) So the SQL operation function can be:
	sql_func()
	{
		select a connection handle from connection handle pool;
		
		/* 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);
		
	}
	
	This will not allocate connection handle and connect database every time. So I think this will improve efficiency.
	
	Nick, could you help to comment on this idea? Such as if it is worth to create a connection handle pool? Is there any risk of implementing this? 

        Thanks very much in advance!
	
Best Regards
Nan Xiao
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
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

Gmane