标签：C

在unixODBC中，SYSTEM_FILE_PATH定义了像odbc.ini和odbcinst.ini这些系统文件存放的位置。默认情况下，是在“/usr/local/etc”这个文件夹下。我们看一下用到SYSTEM_FILE_PATH的地方。

（1）odbcinst_system_file_path

char *odbcinst_system_file_path( char *buffer )
{
    char *path;
    static char save_path[ 512 ];
    static int saved = 0;

    if ( saved ) {
        return save_path;
    }

    if (( path = getenv( "ODBCSYSINI" ))) {
        strcpy( buffer, path );
    strcpy( save_path, buffer );
    saved = 1;
        return buffer;
    }
#ifdef SYSTEM_FILE_PATH
    else {
    strcpy( save_path, SYSTEM_FILE_PATH );
    saved = 1;
        return SYSTEM_FILE_PATH;
    }
#else
    else {
    strcpy( save_path, "/etc" );
    saved = 1;
        return "/etc";
    }
#endif
}

可以看到在查找系统文件路径时，首先会看ODBCSYSINI这个环境变量有没有赋值，如果有，以这个变量定义的值为准，否则如果SYSTEM_FILE_PATH定义了，则用SYSTEM_FILE_PATH。最后才考虑使用“/etc”。

（2）odbc_config的main函数：

int main( int argc, char **argv )
{
    ......
    else if ( strcmp( argv[ i ], "--odbcini" ) == 0 )
    {
        printf( "%s/odbc.ini\n", SYSTEM_FILE_PATH );
    }
    else if ( strcmp( argv[ i ], "--odbcinstini" ) == 0 )
    {
        printf( "%s/odbcinst.ini\n", SYSTEM_FILE_PATH );
    }
    ......
}

可以看到，在使用odbc_config程序获得odbc.ini和odbcinst.ini文件位置时，也要用的SYSTEM_FILE_PATH。

unixODBC（http://www.unixodbc.org）和iODBC（http://www.iodbc.org）是UNIX系统上两个开源的ODBC实现。关于二者的比较，有兴趣的朋友可以参考stackoverflow上的这篇帖子。我没有用过iODBC，所以不好评论孰优孰劣。但是从stackoverflow上关于两个项目的标签统计来看，应该是unixODBC用的更广泛一些。在距离上一版本发布两年以后，今年10月，unixODBC发布了2.3.2版本，基本上就是修正了一些bugs（其中有3个bug是我发现并提出修改意见的），没有新的feature引入。我从2011年开始在项目中使用unixODBC，2012年中旬项目正式上线，到现在已经运行了1年半时间。总的来说unixODBC还是很稳定的，基本连个错误都没有。在这篇文章中，我把我使用unixODBC的一点经验分享出来，希望能给需要的朋友一些帮助。

（1）源码，编译和安装
在unixODBC的网站上提供了最新版本的源码下载，如果想下载之前的发布版本，可以访问这个网站：ftp://ftp.unixodbc.org/pub/unixODBC/。个人感觉，unixODBC的代码风格还是很清晰的，前后也比较一致（unixODBC里面也包含了一些其它开源的代码，像libltdl，而这些开源代码的风格和unixODBC的风格是不一致的）。只是有些函数有些太长了（像SQLConnect函数就有600多行），似乎不符合KISS（Keep It Small and Simple）原则。
编译unixODBC很简单：

./configure；
make；
make install

我的很多同事都说在Solaris环境下编译源代码是很痛苦的事情，但是编译unixODBC却总是一气呵成，连个错误都没有。
此外，由于默认编译unixODBC是优化的，所以我在实验室里使用时一般都是禁止优化的（./configure CFLAGS=’-g -O0 ‘），这样debug时也比较方便，不会出现代码和函数对不上的问题。只有到了生产环境，才把优化打开。

（2）使用连接池
从2.0.0版本起，uinixODBC引入了连接池。unixODBC的项目负责人Nick Gorham在这篇文章里详细介绍了连接池。引入连接池，可以使对数据库连接的使用更高效。下面我就对连接池的原理做个分析：
首先，uinixODBC引入两个全局变量：

/*
 * connection pooling stuff
 */

CPOOL *pool_head = NULL;
int pooling_enabled = 0;

其中pool_head指向连接池链表的首节点，而pooling_enabled则表示是否使用连接池。
其次，在SQLDisconnect函数中，可以看到：

/*
 * is it a pooled connection, or can it go back 
 */

if ( connection -> pooled_connection )
{
    __clean_stmt_from_dbc( connection );
    __clean_desc_from_dbc( connection );

    return_to_pool( connection );

    ......

    return function_return( SQL_HANDLE_DBC, connection, SQL_SUCCESS );
}
else if ( pooling_enabled && connection -> pooling_timeout > 0 ) 
{
    __clean_stmt_from_dbc( connection );
    __clean_desc_from_dbc( connection );

    return_to_pool( connection );

    ......

    return function_return( SQL_HANDLE_DBC, connection, SQL_SUCCESS );
}

如果使用了连接池的话，当断开连接时，连接是回到了连接池里，也就是return_to_pool这个函数。
最后，在SQLConnect函数中，可以看到：

if ( pooling_enabled && search_for_pool( connection, 
                                            server_name, name_length1,
                                            user_name, name_length2,
                                            authentication, name_length3,
                                            NULL, 0 ))
{
    ret_from_connect = SQL_SUCCESS;

    .....

    connection -> state = STATE_C4;

    return function_return( SQL_HANDLE_DBC, connection, ret_from_connect );
}

如果连接数据库时可以在连接池中找到可用的连接（search_for_pool），函数就直接返回，不用再做连接的操作了。

（3）在日志中打印线程
unixODBC的日志输出是通过dm_log_write函数：

if ( !log_info.program_name )
{
    uo_fprintf( fp, "[ODBC][%s]%s[%s][%d]%s\n", __get_pid((SQLCHAR*) tmp ), 
            tstamp_str,
            function_name, line, message );
}
else
{
    uo_fprintf( fp, "[%s][%s]%s[%s][%d]%s\n", log_info.program_name,
        __get_pid((SQLCHAR*) tmp ), 
        tstamp_str,
        function_name, line, message );
}

可以看到，日志输出包含进程名，时间戳，函数名，行号，和消息。但是现在的程序基本是多线程的，所以当有多个线程同时访问数据库时，从日志就很难区分开哪个线程到底做了什么，因此通常我会在日志中增加对线程的打印。因为我们的程序运行在Solaris系统，而在Solaris上，pthread_t类型是个整数，标示当前的线程号，所以下面的改动就可以增加对线程号的输出：

if ( !log_info.program_name )
{
    uo_fprintf( fp, "[ODBC][%s][%d]%s[%s][%d]%s\n", __get_pid((SQLCHAR*) tmp ), pthread_self(),
            tstamp_str,
            function_name, line, message );
}
else
{
    uo_fprintf( fp, "[%s][%s][%d]%s[%s][%d]%s\n", log_info.program_name,
        __get_pid((SQLCHAR*) tmp ), 
        pthread_self(),
        tstamp_str,
        function_name, line, message );
}

由于pthread_t类型在不同的系统定义不一样，所以如果同一份unixODBC代码需要运行在不同系统上，就需要实现定制化：

#ifdef __linux__
......
#endif

#ifdef __sun
......
#endif

关于pthread_t的打印，可以参考stackoverflow上的这篇帖子。
以上就是我使用unixODBC的一点经验分享，希望能给需要的朋友一点帮助。如果大家有其它好的经验，也希望能分享出来。