On 21-Feb-2002 Tim Harsch wrote: > Hi all, > Here's more info on the ODBC not connecting problem. > It doesn't seem to provide much insight, maybe you'll > have better luck though ... > > ----- > Here's a DBI trace of a simple connect attempt: > > DBI 1.21-nothread dispatch trace level set to 2 > Note: perl is running without the recommended perl > -w option > -> DBI->connect(DBI:ODBC:HOMER, omodify, ****, ) > -> DBI->install_driver(ODBC) for linux perl=5.006 > pid=23194 ruid=0 euid=0 > install_driver: DBD::ODBC version 0.38 loaded > from > /usr/lib/perl5/site_perl/5.6.0/i386-linux/DBD/ODBC.pm > <- install_driver= DBI::dr=HASH(0x8182b78) > -> connect for DBD::ODBC::dr > (DBI::dr=HASH(0x8182b78)~0x8158388 'HOMER' 'omodify' > **** HASH(0x815ec18)) > Driver connect 'HOMER', 'omodify', 'xxxx' > SQLConnect 'HOMER', 'omodify', 'xxxx' > dbd_error: SQLError returned -2 unexpectedly. > dbd_error: SQLError returned -2 unexpectedly.
-2 is SQL_INVALID_HANDLE - it probably means a call to SQLAllocHandle for the environment (most likely) or connection handle failed. Sometimes the reason for this is there is somthing set for user A (like an environment variable e.g. ODBCHOME) that is not set for user B. When you use LogonUser=userB then SQLAllocHandle for the environment fails. All this is delayed with OOB as it does nothing until the application actually calls SQLDriverConnect or SQLConnect. Once the app (perl in this case) calls one of those functions, OOB client contacts server, verifies authentication with LogonUser/LogonAuth, then calls SQLAllocHandle for env, for dbc and finally SQLDriverConnect for the remote driver. <snipped rest of log> Your earlier posting with an OOB log indicates this too as all the calls on connection handles give SQL_INVALID_HANDLE. The OOB log you also posted has the start stripped off and unfortunately the connection handle was allocated in this part of the log. If we had this, the problem would be more easily identified. If I understand your other postings correctly, you are saying make test works but perl run after make install don't - yes? However, in yet a later posting you say OOB test programs connect to your server fine but perl through unixODBC and OOB do not. I think this is the giveaway. unixODBC uses dlopen to open the driver and dlsym to resolve the symbols in the driver. If the wrong options for your platform are passed to dlopen unixODBC can end up resolving some of the SQL function symbols in itself instead of in the driver. What then happens if that handles passed back to unixODBC from OOB can end up being passed in to unixODBC functions. You can confirm this by linking DBD::ODBC directly with OOB i.e. set ODBCHOME to /x/y/easysoft/oob/client. If it works then the likely reason is you are running a version of unixODBC that has picked the wrong LAZY/NOW etc flags for the dlopen call - it is some mismatch between the way perl was built and unixODBC - you might recollect the start of make test for DBD::ODBC outputting PERL_DL_NONLAZY=1. I have seen this happen before with older unixODBCs but Nick fixed it. If you need unixODBC and are running an old copy then get a new one from ftp://ftp.easysoft.com/pub/beta/unixODBC (current version 2.2.0 I think). Alternatively, you will need to edit the libltdl/ltdl.c file in unixODBC and switch the flags to dlopen. If you don't need unixODBC or are so pushed for time you just need to get this working now, link DBD::ODBC directly with OOB. Martin -- Martin J. Evans Easysoft Ltd, UK Development
