Martin, Jeff et al. You guys nailed it I think. I think in my previous working set up I had I must have chosen /usr/local/easysoft/oob/client as my ODBCHOME
For this failed build of ODBC 0.38 I had been choosing /usr/local/easysoft/unixODBC as my ODBCHOME I switched back to /usr/local/easysoft/oob/client as my ODBCHOME and all is well again. So, if I understand from an offline with Jeff, the /usr/local/easysoft/oob/client is the ODBC driver itself and: /usr/local/easysoft/unixODBC is ODBC driver manager. I don't understand why but the driver manager doesn't seem to be working correctly for me. If I find out I'll let you all know. Thanks so much for everyone's help. The DBI users list is a good community. Ciao, --- [EMAIL PROTECTED] wrote: > 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 > __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com
