gmane.comp.db.unixodbc.devel

Linking Static Lib(UnixODBC) In Another StaticLib(libodbc++-mt.a)

Prabu RM — 2013-05-27T09:59:56

Hi Support,

In linux linking a static lib to another static is not so easy and we
believe that it is not supported. In order to achieve that we need to
extract both the .a separately to their objects and need to make them
single.

But in UnixODBC/LibODBC we used to keep our application which binds both
UnixODBC & LibODBC in static.

Eg: /usr/local/lib/libodbc++-mt.a, /usr/local/lib/libodbc.a

The connectivity b/w our application and MySQL server looks like below.

*Application Binary(c++) -> LibODBC -> UnixODBC -> MySQL Driver -> MySQL
Server*
*
*
If so how do you link *UnixODBC Static Lib(*libodbc.a*) *in* LibODBC Static
Lib(*libodbc++-mt.a*) creation?*
*
*
Thanks Advance,
Regards,
Prabu RM.
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev< at >mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev

ODBC driver information

Aistis Jokubauskas — 2013-04-24T09:29:09

Hi,

is it possible to get odbc driver information. I would like to get 
driver name and version using odbc api.

lt_dlerror may cause potential issue in multi-threadenvironment

xiaonan — 2013-04-12T01:40:09

 Hi, Nick:

    Because lt_dlerror() function is not thread-safe, in the following code:
    
    if ( !(connection -> dl_handle = odbc_dlopen( driver_lib )))
    {
        char txt[ 2048 ];

        sprintf( txt, "Can't open lib '%s' : %s",
                driver_lib, lt_dlerror());

        ......
        
        return 0;
    }
    
    In multi-thread environment, the lt_dlerror() may return other thread's error, or even NULL.
    
    In your latest modification:
    
    if ( !(connection -> dl_handle = odbc_dlopen( driver_lib )))
    {
        char txt[ 2048 ];
        const char *err;

        err = lt_dlerror();

        sprintf( txt, "Can't open lib '%s' : %s",
                driver_lib, err ? err : "NULL ERROR RETURN" );

        ......
        return 0;
    }
    
    This issue still exits.
    
    Personally, I think the function of odbc_dlopen() can be modified as this:
    
    static void *odbc_dlopen( char *libname, char *err );
    {
        ......
        hand = lt_dlopen( libname );

RHEL 5 Linux UnixODBC/Freetds

Prasanna Srinivasan — 2013-04-12T01:37:26

Am trying to move my compiled C code that connects to mssql database
servers from using the datadirect odbc drivers to using the unixodbc
driver manager (version 2.3.1)/ freetds drivers (version 0.91) which
are already compiled for 64 bit and available to me.

Am able to successfully compile it on 64 bit RHEL5 Linux by linking in
libodbc which has already been compiled. But I get the error
net.c:350: tds_select: Assertion 'timeout_seconds >= 0' failed
multiple times when I run the code and the database connection fails.

The environment variables I set are ODBCINI, ODBCHOME and
LDD_LIBRARY_PATH (which is set to the libraries in the unixodbc path).
The driver in the odbcinst file is set to the path where libtdsodbc.so
is located.
 The permissions on the odbc.ini, odbcinst.ini files appear to be fine.

I also tried linking in libodbinst and libtdsodbc (by including and
not including libodbc)  when compiling and set the FREETDSCONF
environment variable as well to the freetds.conf location. But I keep
getting th

A multi-thread contention issue when using lt_dlinitfunction

xiaonan — 2013-04-11T06:24:47

 Hi, Nick:

    Sorry for interrupting you again!
    
    Because libltdl functions are not thread-safe (http://www.gnu.org/software/libtool/manual/html_node/Thread-Safety-in-libltdl.html), we should add lock before using them.
    
    In __connect_part_one function:
    {
        ......
        /*
         * initialize libtool
         */
    
        lt_dlinit();
        ......
        
        if ( !(connection -> dl_handle = odbc_dlopen( driver_lib )))
        {
           ......
        }
     }
    
     int lt_dlinit (void)
     {
         ......
         if (++initialized == 1)
         {
            ......
         }
    
     }
    
     In multi-thread environment, there will be a scenario: Thread 1 calls lt_dlinit(), and the initialized's value is 1. Then Thread 2 calls lt_dlinit(), and the initialized's value is changed to 2. Thread 2 thinks the initializtion is OK, so it will continue executing and calls odbc_dlopen(). But in fact, the initialization isn't done! So odbc_dlopen() will return N

A core dump issue in __connect_part_one function

xiaonan — 2013-04-10T09:17:05

 Hi, Nick:

    Sorry for interrupting you!
    
    When I using unixODBC, there will be core dump sometimes. The cause is in __connect_part_one and __connect_part_two functions:
    
    if ( !(connection -> dl_handle = odbc_dlopen( driver_lib )))
        {
            char txt[ 2048 ];

            sprintf( txt, "Can't open lib '%s' : %s",
                    driver_lib, lt_dlerror());
            ......
         }
         
         The lt_dlerror() return value is NULL.
         
         Because lt_dlerror() can return NULL, I think we should justify the return value of lt_dlerror before using sprintf.
         
         BTW, I think LT__GETERROR and LT__SETERRORSTR are not thread-safe, so the return value of lt_dlerror can be NULL.
 
Best Regards
Nan Xiao
   
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev< at >mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev

Handling out-of-memory

Heikki Linnakangas — 2013-02-28T08:04:14

Hi,

While working on the PostgreSQL driver, I bumped into two little bugs in 
handling out-of-memory situation. Patch attached. It's probably 
self-evident from the patch what the bugs are, but I'll explain anyway:

1. In __post_internal_error_ex, check for NULL return from malloc, and 
avoid some unnecessary allocations so that we don't need to handle the 
case that they fail. (In my test case, the reason that 
__post_internal_error_ex got called in the first place was that dlopen() 
failed with Out-of-Memory while loading the driver, so it's not 
surprising that those allocations failed too)

2. In __alloc_desc, there is a check for calloc returning NULL, but some 
of the initialization code was misplaced, and was being called on the 
NULL pointer anyway.

There are a lot more places where we don't check for malloc returning 
NULL, but fixing those two made my test case work. In the test case, I 
opened a large number of connections, and to induce the OOM condition, I 
ran it with a small "ulimit -v".

-

A issue about return_to_pool function

xiaonan — 2012-11-20T09:28:25

 Hi, Nick:
    Sorry for interrupting you.

    In return_to_pool() function, I think the unicode_driver should also be set:
   ptr -> connection.unicode_driver = connection ->unicode_driver;

   If this value not set, the search_for_pool() return the connection's unicode_drive's value is always 0. This will lead error when using unicode driver.

    Please help to check it, thanks very much!!

Best Regards
Nan Xiao




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

A issue about return_to_pool function

xiaonan — 2012-11-20T09:28:25

 Hi, Nick:
    Sorry for interrupting you.

    In return_to_pool() function, I think the unicode_driver should also be set:
   ptr -> connection.unicode_driver = connection ->unicode_driver;

   If this value not set, the search_for_pool() return the connection's unicode_drive's value is always 0. This will lead error when using unicode driver.

    Please help to check it, thanks very much!!

Best Regards
Nan Xiao




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

Buffer Overflow Study at Auburn University - unixODBC developers I would really appreciate your help!

Auburn Study — 2012-11-08T14:48:29

Hi All,

I am a graduate student at Auburn University, working with Dr. Munawar
Hafiz. We are working on an empirical study project to understand the
software engineering practices used in companies that produce secure
software. In particular, we are concentrating on how developers write
code to prevent buffer overflow and integer overflow vulnerabilities.
We are interested in the software development process: how you develop
software, how you test and analyze programs to detect vulnerabilities,
and what processes you follow to remove bugs. We are looking into
automated tools that software developers use, and are expecting that
there is a common insight in the security engineering process that can
be reusable.

We request your assistance by participating in this research study.
We would greatly appreciate it if you would share your experience with
us by answering the questions at the end of this email. We may send
some follow up questions based on your response in future. Your
response(s) will be kept confid

I am getting "Function Sequence Error" When I try to do SQLDescribeParam() using my native ODBC

Aniruddha Kulkarni — 2012-11-08T12:24:23

Hi,

I am stuck with some issue here. I am trying to do certain operations on back-end using my native ODBC driver however when I call SQLDescribeParam() through my application it gives me an error as - SQLDescribeParam -> Rc = SQL_ERROR, Msg = [unixODBC][Driver Manager]Function sequence error

Here is the scenario which encountered this problem:

1>   Connect to backend using SQLConnect()

2>   Prepare an insert query having geometry as col type using SQLPrepare()

3>   Set the statement attributes using SQLSetStmtAttr()

4>   Bind the parameters with the data type using SQLBindParameter()

5>   Then execute the parameterized query using - SQLExecute()

6>   Call SQLNumParams() on statement

7>   Then in a loop, call SQLDescribeParam() with the appropriate function arguments.

With this sequence of functions I am getting the mentioned error. My doubt is on unixODBC driver manager I have been using, because if I try to run the application without DM then it works as expected. So I believe there is some error

when to return SQL_NO_DATA fromSQLExecute/SQLExecDirect

Peter Harvey — 2012-10-30T09:48:46

Christian,

drvexecute returns SQL_NO_DATA, as follows, when I submit a simple
"CREATE TABLE" statement.

    if (*s->ov3 && !s->isselect && ret == SQL_SUCCESS && nrows == 0) {
    ret = SQL_NO_DATA;

My take on the specification is that this is not a time to return
SQL_NO_DATA. This should be SQL_SUCCESS. I may be wrong?

--
Cheers
Peter


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

double free

Peter Harvey — 2012-10-30T09:23:51

Nick,

Getting a 'double free' error in SQLGetDiagFieldW when requesting
message text from a record. This does *not* happen when I use a wchar
version of driver.

The following shows the offending code (from SourceForge). Note; works
if I comment out the call for free() in here;

      case SQL_DIAG_MESSAGE_TEXT:
        {
           SQLWCHAR *str;
            int ret = SQL_SUCCESS;

            str = ptr -> msg;

            if ( diag_info_ptr )
            {
                if ( buffer_length >= wide_strlen( str ) + 1 )
                {
                    wide_strcpy( diag_info_ptr, str );
                }
                else
                {
                    ret = SQL_SUCCESS_WITH_INFO;
                    memcpy( diag_info_ptr, str, ( buffer_length - 1 ) * 2 );
                    (( SQLWCHAR * ) diag_info_ptr )[ buffer_length - 1 ]
= '\0';
                }
            }
            if ( string_length_ptr )
            {
                *string_length_ptr = wide_strlen( str );
            }
prin

segfault

Peter Harvey — 2012-10-30T08:10:23

Hey Nick,

Playing around with an ODBC problem. Possible bug in unixODBC. Built
sqliteodbc3 driver without wchar support (oversight) and then had my app
(which is built for UNICODE) call;

SQLPrepare
SQLExecute (fails as I expect)

Then the following segafults... 

SQLGetDiagField( nType, hHandle, 0, SQL_DIAG_DYNAMIC_FUNCTION, NULL, 0, &nChars );

This seems to be caused by using a null function pointer in the function array - presumably because the driver does not have SQLGetDiagFieldW. I would think that the DM would check for null function pointer.

Let me know if you want me to fix this (ie in the sourceforge repo).

--
Cheers
Peter
BTW: I know that I should expect SQL_ERROR from the SQLGetDiagField call in this case - just not a segfault ;)
 

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

SQLFETCH api is crashing

Radhesh Krishnan K — 2012-07-20T11:17:31

Hi all,

I was trying to use odbc api for my application. And my application is
crashing inside the sqlfetch odbc api.
Version of unixODBC is 2.3.1.

This is the backtrace I got from gdb :

#0  0xffffe424 in __kernel_vsyscall ()
#1  0x002a7df0 in raise () from /lib/libc.so.6
#2  0x002a9701 in abort () from /lib/libc.so.6
#3  0x002e03ab in __libc_message () from /lib/libc.so.6
#4  0x00367031 in __stack_chk_fail () from /lib/libc.so.6
#5  0x446d4f74 in ?? () from /usr/lib/libodbc.so.1
#6  0x446e240c in shmget () from /usr/lib/libodbc.so.1
#7  0xbfea4788 in ?? ()
#8  0x4468fad6 in SQLFetch () from /usr/lib/libodbc.so.1

I am not able to figure it out what is the problem! Could someone help me
to resolve this issue.

Where should one install .so files?

Jean-Michel Vourgère — 2012-07-14T11:55:01

Hello

I'm working on mdbtools, that includes a really free odbc driver for microsoft access files.

I'm used to Debian GNU/Linux OS, and I noticed that most drivers are installing themselves in /usr/lib/odbc rather that just /usr/lib. (Then it changed to /usr/lib/i386/odbc, but that is another story...)
That way, odbcinst.ini only have to reference "Driver = libmdbodbc.so.1" without any path.

But general "upstream" makefile installs in lib/ and not lib/odbc.

My question is where should a driver install itself on most architectures: lib/ or lib/odbc/ ?

Is the odbc subfolder a general thing for distros? Or just a Debian/Ubuntu specific thing?

Thank you!

Error on Fisrt steps for noob

Reinaldo A. Fagundes — 2012-06-28T12:28:13

hi,

    Sorry my noob question.

    I try run unixODBC and FreeTDS but still having problem, I try connect with tsql and run fine, but with isql no, and with software in .c no run.

    need help to solve this please.

    let me show.

    tsql:
        ts7500:~# odbcinst -s -q
        [MSSQLTestServer]
        [NSSQL]
        ts7500:~# odbcinst -d -q
        [FreeTDS]
        ts7500:~# tsql -S MSSQLTestServer -U sa
        Password:
        locale is "C"
        locale charset is "ANSI_X3.4-1968"
        using default charset "ISO-8859-1"
        1> use Teste
        2> select * from tabela1
        3> go
        ID      Nome
        1       Reinaldo
        3       Charles
        10      Teste
        (3 rows affected)
        1>

    Now isql
        ts7500:~# isql MSSQLTestServer sa **** -v
        [S1000][unixODBC][FreeTDS][SQL Server]Unable to connect to data source
        [01000][unixODBC][FreeTDS][SQL Server]Adaptive Server connection failed
        [01000][unixODBC][FreeTDS][SQL Server]Unexpect

MS SQLServer drivers / Linux ODBC Driver Manager

Duncan Kerr — 2012-03-07T16:44:32

Im connecting to SQLServer using the above, using unixODBC-2.3.1.  My test program works fine, my main application fails after successfully connecting to the database when it calls SQLGETDIAGRECW on line 4447 of __info.c.  mky stack looks is below, and the arguments to SQLGETDIAGRECW are

SQLGETDIAGRECW(connection=0x00000000006c19c0,
           head->handle_type = 2,
           handle=0x000000000070e650,
rec_number=1,
sqlstate={31152,65535,2,0,94,0},
&native (native=0),
msg1=0x0000fffffff74c0 (byte 0 = NULL)
sizeof(msg1),
&len (len=260545));

My test program has similar arguments, except sqlState={31856,99,0,0,75,0} and works fine.  Any ideas folks?

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff78390e9 in ?? () from /opt/microsoft/sqlncli/lib64/libsqlncli-11.0.so.1720.0
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.7.el6.x86_64 keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.8.2-3.el6.x86_64 libcom_err-1.41.12-3.el6.x86_64 libgcc-4.4.4-13.el6.x86_64 libselinux-2.0.94-2.el6.x8

Calling a store procedure

Jaime Stuardo — 2012-02-23T03:05:22

Hello I am trying to call a SQL Server 2005 stored procedure by mean of a
C++ application running under RedHat Linux. unixODBC is installed correctly
since I can connect to the database.

 

When I run SQLExecDirect, the returned value is an error. So, here are the
questions:

 

·         Why does an error occur?

·         Why does the SQLGetDiagRec function cannot return the actual
error? If I generate an error passing a string instead of a date in the
second parameter, the error is: [FreeTDS][SQL Server]Error converting data
type varchar to datetime. That means ExtractError function I implemented is
correct.

 

This is the code with SQLExecDirect:

 

    ret = SQLExecDirect(stmt, (SQLCHAR *) query.c_str(), SQL_NTS);

    if (!SQL_SUCCEEDED(ret)) {

        StoreSocket::ExtractError("SQLExecDirect", stmt, SQL_HANDLE_STMT);

        return false;

    }

 

Where query is:

execute usp_contrato_actualiza_aclaracion 'uno', '2012-02-22', 'dos',
'tres', 'cuatro', '2012-02-14', 'cinco', 'seis', 'siete',

2.3.1

Nick Gorham — 2011-12-01T01:58:50

Hi,

Its that time again. I have pushed a 2.3.1 build to the web and ftp 
site, As always any problem let me know.

Thanks.

unixodbc-gui-qt 2.3.0 tarball?

Steve Langasek — 2011-08-23T06:50:01

Hi there,

The unixODBC 2.3.0 release has been out for some time now, dropping the GUI
tools which are now a separate project
(http://sourceforge.net/projects/unixodbc-gui-qt/).  However,
http://sourceforge.net/projects/unixodbc-gui-qt/files/ says that "this
project has no files", and there are no tags in the svn repo.  Is there a
2.3.0 release tarball for unixodbc-gui-qt available somewhere?  If not, is
there any hope of this happening soon?

Thanks,