gmane.comp.db.unixodbc.devel

Re: ODBC driver information

Aistis Jokubauskas — 2013-04-24T09:49:02

Thank you! (bow)

Re: ODBC driver information

Martin J. Evans — 2013-04-24T09:36:19

Look at the SQLGetInfo API call. You can get all that and more.

Martin

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.

Re: Compiling unixODBC with MySQL driver on AIX

Tom Lane — 2013-04-12T13:53:40

There's quite a bit of stuff that doesn't work out-of-the-box in
current mysql-connector-odbc.  You might find some useful patches in
Red Hat's version: 
http://pkgs.fedoraproject.org/cgit/mysql-connector-odbc.git/tree/

You won't need the "mysys" patch if you're using a stock libmysqlclient,
but the rest of it is probably relevant.  Also I should note that we
have not tried to build this against anything later than mysql 5.5;
I dunno if 5.6 would require further hacking.

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

Re: lt_dlerror may cause potential issue in multi-thread environment

Nick Gorham — 2013-04-12T10:18:40

Yes, you are right, I should read my own code a bit closer. I will do 
what you suggest.

Compiling unixODBC with MySQL driver on AIX

2013-04-12T10:23:11

Hello,
I'm trying to get unixODBC working on AIX 7.1, so far I have done the following:


1) I have downloaded unixODBC 2.3.0 and compiled it with the following options:

export CC=xlc_r
export CXX=xlC_r
export CFLAGS="-q32 -qlanglvl=extended -ma -O2 -g -qstrict -qoptimize=2 -qmaxmem=8192"
export CXXFLAGS="-q32 -ma -O2 -g -qstrict -qoptimize=2 -qmaxmem=8192"
export LDFLAGS="-Wl,-brtl"
export OBJECT_MODE=32

./configure --enable-gui=no --enable-drivers=no > c.log

N.B: The install script does not seem work correctly on AIX 7.1.


2) I then downloaded MySQL 5.6.10:

wget http://dev.mysql.com/get/Downloads/MySQL-5.6/mysql-5.6.10.tar.gz/from/http://cdn.mysql.com/ -O mysql-5.6.10.tar.gz

and added the following to CMakeLists.txt:

SET(CMAKE_C_FLAGS "-q32 -qlanglvl=extended -ma -O2 -g -qstrict -qoptimize=2 -qmaxmem=8192 -lC -liconv" CACHE STRING "Forced C compiler flags." FORCE)
SET(CMAKE_CXX_FLAGS "-q32 -ma -O2 -g -qstrict -qoptimize=2 -qmaxmem=8192" CACHE STRING "Forced C++ compiler flags." FORCE)
SET(CMAKE_C_CO

Re: lt_dlerror may cause potential issue in multi-thread environment

xiaonan — 2013-04-12T09:51:38

Hi, Nick:

    Your response:
     a context shift can happen between dlopen and dlerror so the error may relate to the other thread.

    Because there is a lock, why other threads can enter this critical Section? Thanks!

Best Regards
Nan Xiao
At 2013-04-12 14:59:02,"Nick Gorham" <nick< at >lurcher.org> wrote:

On 12/04/13 02:40, xiaonan wrote:

 Hi, Nick:

    Because lt_dlerror() function is not thread-safe, in the following code:


Ok, I misunderstood your problem. I would say the solution is to wrap the calls with the mutext to force it into being thread safe. But you still run the risk if the driver does the same thing and not using the mutext so it will still have the same problem.

    
    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 er

Re: RHEL 5 Linux UnixODBC/Freetds

Frediano Ziglio — 2013-04-12T09:47:51

2013/4/12 Prasanna Srinivasan <psriniboise< at >gmail.com>

I don't remember to have seen this error before!



it's LD_LIBRARY_PATH.




If you want to use unixODBC you need to link to odbc, not to our driver
directly. DM (unixODBC) will load the driver for you.

Frediano


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

Re: lt_dlerror may cause potential issue in multi-thread environment

Nick Gorham — 2013-04-12T06:59:02

Ok, I misunderstood your problem. I would say the solution is to wrap 
the calls with the mutext to force it into being thread safe. But you 
still run the risk if the driver does the same thing and not using the 
mutext so it will still have the same problem.

Bit that still doesnt help. a context shift can happen between dlopen 
and dlerror so the error may relate to the other thread. If I understand 
correctly, all you have done is reduce the time between the dlopen and 
dlerror, its still not atomic.

Re: RHEL 5 Linux UnixODBC/Freetds

Nick Gorham — 2013-04-12T06:54:27

Thats from the driver not unixODBC. I would guess its debug relating to 
timeouts not being implemented. I would ask the freetds folk, or suggest 
another driver (I am biased, the Easysoft one comes to mind :-)).

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

Re: A multi-thread contention issue when using lt_dlinit function

Nick Gorham — 2013-04-11T18:24:12

Changes checked in.

Re: A multi-thread contention issue when using lt_dlinit function

Nick Gorham — 2013-04-11T06:31:47

Yes, I see what you are saying, I will look at adding that mutex.

Re: ODBC-api hooking problem

Nick Gorham — 2013-04-11T06:29:37

Hmm, I guess my answer is I don't know to that.

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

Re: ODBC-api hooking problem

Динар Рахимбаев — 2013-04-11T06:18:44

10.04.2013 22:24, Nick Gorham пишет:
Thanks a lot for your quick responses!

Now I'm going to try another way (direct access to DBMS driver). I 
think, I'll get more definite behavoir. But I'll have to include some 
driver manager logic into my driver. This is what I wanted to avoid 
trying to use the driver manager twice.

Ok! But, another questions: is there any way to force loading the copy 
of driver manager image on demand? And how dynamic linker ( more 
prcisely dl_sym() ) will resolve the symbols? I experienced the problem 
of that dl_sym() gets me entry pionts of my driver instead of ones in 
newly loaded shared object when I used dlopen() to load it (dlmopen() 
with LM_ID_NEWLM option solved this problem).
_______________________________________________
unixODBC-dev mailing list
unixODBC-dev< at >mailman.unixodbc.org
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev

Re: A core dump issue in __connect_part_one function

Nick Gorham — 2013-04-10T18:28:26

I have uploaded a simple fix that should fix this.

Re: ODBC-api hooking problem

Nick Gorham — 2013-04-10T18:24:49

Yep, in theory it should work, but I can imagine there may be some 
reentrancy issues going on. It would probbaly be safer to make your 
driver call the targer driver directly.

Re: ODBC-api hooking problem

jon pounder — 2013-04-10T15:51:01

I don't know for sure but I am guessing having 2 instances of the dm 
loaded in the same process is causing trouble since there is only one 
odbc environment per process.


you should be able to simply call the dbms driver from within your own 
driver though, every function do your special stuff then call the same 
func in the driver - thats basically what the dm does now.



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

ODBC-api hooking problem

Динар Рахимбаев — 2013-04-10T15:45:16

Good afternoon!

I have a problem of hooking ODBC-api calls to perform some authority 
check of SQL-requests. I decided that it is possible if I developed my 
own driver, which would pass calls from driver manager  to the next 
DBMS-specific driver, or again to the driver manager(driver manager then 
would call DBMS specific driver) after authority check.
I decided to implement my custom driver by the second way (i.e. driver 
passes calls to the driver manager), because the driver manager performs 
many routine work of managing environment and connections. So my custom 
driver loads the driver manager (libodbc.so) using dlmopen(), extracts 
the entry points using dlsym(), then just passes calls to the 
corresponding functions of newly loaded driver manager.

I'm getting SIGSEGV when my driver passes the call to driver manager's 
SQLConnect() function.

So my question is: is it possible at all to use the driver manager in a 
such scheme?

/****************************************************

Applicaion -> Dr