Nick Gorham | 31 Aug 22:35 2015

Just like buses here comes 2.3.4

An unnoticed (till now) typo in 2.3.3 caused any attempt to load the 
cursor lib to fail. So I have updated the current build to contain this 
fix and its now 2.3.4. This is the build on the web site and sourceforge 
now as current.

Hopefully not to many other mistakes on my part in there. It was too 
much of a mistake to wrap in 2.3.4pre and sit on it for a year.

Thanks to Axel for spotting it.

Sorry for any inconvenience this may have caused folk. But if you are 
not using the cursor lib, its not going to bite you.

--

-- 
Nick

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

Kevin Adler | 19 Aug 00:33 2015
Picon

2.3.3 release ETA?

Hi Nick, are there any plans to release 2.3.3? It's been almost 2 years 
since 2.3.2 was released and there are quite a few changes piled up 
judging by the current ChangeLog in SVN. I want to push Debian (and by 
proxy Ubuntu) to update to the latest unixODBC release before Ubuntu 16.04 
ships next April, but if 2.3.3 is coming out soon, I'd just wait for that.

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

Kevin Moody | 4 Apr 00:37 2015

ODBC 2.2.8 automake failing on EL5

Hi All,

 

First off, please let me know if obscure build questions are meant for the support mailing list.  I’ll gladly post there.  I just wasn’t sure.

 

Second, our ODBC 2.2.8 build, which was working fine on our old RHEL 4 build machines, fails to configure properly on both our 32-bit and 64-bit CentOS 5.8 machines. 

 

Here is what we are seeing:

 

make[6]: Nothing to be done for `install-data-am'.

make[6]: Leaving directory `/builds/jenkins/workspace/build/objydb/develop/8ebc22e0/src/sql/unixODBC/src/DRVConfig/drvcfg1'

make[5]: Leaving directory `/builds/jenkins/workspace/build/objydb/develop/8ebc22e0/src/sql/unixODBC/src/DRVConfig/drvcfg1'

Making install in drvcfg2

make[5]: Entering directory `/builds/jenkins/workspace/build/objydb/develop/8ebc22e0/src/sql/unixODBC/src/DRVConfig/drvcfg2'

cd ../.. && \

/bin/sh /builds/jenkins/workspace/build/objydb/develop/8ebc22e0/src/sql/unixODBC/linux86_64/src/missing --run automake-1.7 --gnu DRVConfig/drvcfg2/Makefile

configure.in:3: error: m4_defn: undefined macro: _m4_divert_diversion

aclocal.m4:6425: AM_INIT_AUTOMAKE is expanded from...

configure.in:3: the top level

autom4te: /usr/bin/m4 failed with exit status: 1

configure.in: no proper invocation of AM_INIT_AUTOMAKE was found.

configure.in: You should verify that configure.in invokes AM_INIT_AUTOMAKE,

configure.in: that aclocal.m4 is present in the top-level directory,

configure.in: and that aclocal.m4 was recently regenerated (using aclocal).

 

My internet search yielded this: http://www.delorie.com/gnu/docs/autoconf/autoconf_163.html

 

But, my autoconf/automake knowledge is weak, at best.  I was hoping to figure out if there is a patch to configure.in that I could apply.

 

autoconf (GNU Autoconf) 2.59

automake (GNU automake) 1.9.6

 

Regards,

Kevin

 

_______________________________________________
unixODBC-dev mailing list
unixODBC-dev <at> mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
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

Gmane