Martin,

thanks for your patience.

Martin J. Evans wrote:
On 22-Feb-2005 Walter Obermiller wrote:

Martin,



Martin J. Evans wrote:

The DontDlClose was a suggestion to stop the seg faulting on exit.

When I said you can use DSN=emanuel-sbart;UID=*;PWD=*; I did of course mean
to
say you need to keep the 'dbi:ODBC' on the front. i.e.

'dbi:ODBC:DSN=emanuel-sbart;UID=*;PWD=*;'

blush :-)

I have fixed that now.


You haven't actually shown your DBI->connect now. With DBD::ODBC 1.13 if I do:

here's what I do, and I think it is consistent with what you suggested:

  my $dbh
      = DBI->connect('dbi:ODBC:DSN=emanuel-sbart;UID=**;PWD=**;')
            || die "can't connect to $data_source: $DBI::errstr";
      $rc = $dbh->disconnect;
  exit();



perl -e 'use DBI;my $dbh = DBI->connect("dbi:ODBC:DSN=test;UID=Martin_Evans;PWD=easysoft;");' omitting the username/password arguments

OR

perl -e 'use DBI;my $dbh =
DBI->connect("dbi:ODBC:DSN=test;UID=Martin_Evans;PWD=easysoft;","","");'
specifying empty username/password arguments

it works fine:

Str In = [DSN=test;UID=Martin_Evans;PWD=********;][length = 39]

Looking at the code in DBD::ODBC it just passes the string straight through if
it finds a DSN/UID/PWD. I compared DBD::ODBC 1.13 and 1.06 and I can't see this
has changed but you never know. Running with:

DBI_TRACE=8=dbitrace.log perl myscript.pl

Thats what the tracefile looks like:

DBI 1.43-ithread default trace level set to 0x0/8 (pid 26246)
Note: perl is running without the recommended perl -w option
-> DBI->connect(dbi:ODBC:DSN=emanuel-sbart;UID=walter;PWD=foo;, , ****)
-> DBI->install_driver(ODBC) for linux perl=5.008005 pid=26246 ruid=100 euid=100
install_driver: DBD::ODBC version 1.06 loaded from /usr/lib/perl5/vendor_perl/5.8.5/i586-linux-thread-multi/DBD/ODBC.pm
New DBI::dr (for DBD::ODBC::dr, parent=, id=)
dbih_setup_handle(DBI::dr=HASH(0x8251c10)=>DBI::dr=HASH(0x82ce1a0), DBD::ODBC::dr, 0, Null!)
dbih_make_com(Null!, 0, DBD::ODBC::dr, 92, 0) thr#8151008
dbih_setup_attrib(DBI::dr=HASH(0x82ce1a0), Err, Null!) SCALAR(0x820c66c) (already defined)
dbih_setup_attrib(DBI::dr=HASH(0x82ce1a0), State, Null!) SCALAR(0x82b2520) (already defined)
dbih_setup_attrib(DBI::dr=HASH(0x82ce1a0), Errstr, Null!) SCALAR(0x82b24fc) (already defined)
dbih_setup_attrib(DBI::dr=HASH(0x82ce1a0), TraceLevel, Null!) 0 (already defined)
dbih_setup_attrib(DBI::dr=HASH(0x82ce1a0), FetchHashKeyName, Null!) 'NAME' (already defined)
<- install_driver= DBI::dr=HASH(0x8251c10)
!! warn: 0 CLEARED by call to default_user method
-> default_user in DBD::_::dr for DBD::ODBC::dr (DBI::dr=HASH(0x8251c10)~0x82ce1a0 undef undef HASH(0x821d77c)) thr#8151008
<- default_user= ( undef undef ) [2 items] at /usr/lib/perl5/vendor_perl/5.8.5/i586-linux-thread-multi/DBI.pm line 577 via odbc-emanuel-test.pl line 17
-> connect for DBD::ODBC::dr (DBI::dr=HASH(0x8251c10)~0x82ce1a0 'DSN=emanuel-sbart;UID=**;PWD=**;' undef **** HASH(0x82cf4d0)) thr#8151008
New DBI::db (for DBD::ODBC::db, parent=DBI::dr=HASH(0x82ce1a0), id=)
dbih_setup_handle(DBI::db=HASH(0x82ce164)=>DBI::db=HASH(0x82cf4c4), DBD::ODBC::db, 824edf8, Null!)
dbih_make_com(DBI::dr=HASH(0x82ce1a0), 82b5ce0, DBD::ODBC::db, 220, 0) thr#8151008
dbih_setup_attrib(DBI::db=HASH(0x82cf4c4), Err, DBI::dr=HASH(0x82ce1a0)) SCALAR(0x8256234) (already defined)
dbih_setup_attrib(DBI::db=HASH(0x82cf4c4), State, DBI::dr=HASH(0x82ce1a0)) SCALAR(0x8256294) (already defined)
dbih_setup_attrib(DBI::db=HASH(0x82cf4c4), Errstr, DBI::dr=HASH(0x82ce1a0)) SCALAR(0x8256264) (already defined)
dbih_setup_attrib(DBI::db=HASH(0x82cf4c4), TraceLevel, DBI::dr=HASH(0x82ce1a0)) 0 (already defined)
dbih_setup_attrib(DBI::db=HASH(0x82cf4c4), FetchHashKeyName, DBI::dr=HASH(0x82ce1a0)) 'NAME' (already defined)
dbih_setup_attrib(DBI::db=HASH(0x82cf4c4), HandleSetErr, DBI::dr=HASH(0x82ce1a0)) undef (not defined)
dbih_setup_attrib(DBI::db=HASH(0x82cf4c4), HandleError, DBI::dr=HASH(0x82ce1a0)) undef (not defined)
-------------





will provide a trace which should show what DBD::ODBC is using.

I'd still like to see your DBI->connect call though.

Thanks,

        -walt














Ok, got one step further.

Now the test program no longer segfaults, but seems to go into an
endless loop, trying to connect WITHOUT UID and password, and it gets snubbed by the Adabas library for that (see sql.log below).


Window Hdl = (nil)
Str In = [DSN=emanuel-sbart;UID=walter;PWD=***;;UID=;PWD=;][length = 48]


It seems, as if additional empty UID and PWD fields contents get tacked at the end of the connection string so that UID and PWD get passed onto the ADABAS-Driver empty. The question now is: what is doing such an ungodly thing ?


Furthermore the programs size grows constantly (memleak).


I'd guess this is a bug in your adabas driver - it needs to return SQL_NO_DATA
when there are no more diags left and it looks as though it doesn't. We have a
recollection of this being found in PHP on a PHP mailing list somewhere.

BTW, I spoke to Nick Gorham and he reminded my what the mixing
thread/non-thread applications, drivers and driver managers problem on Linux
is. We think the problem is that the internal structure used by dlopen is bigger
when built threaded. You can reproduce this with an ODBC app built without
-D_REENTRANT an without linking with pthreads (e.g. without gcc -pthread) and
then run it against a unixODBC built threaded.

Martin
--
Martin J. Evans
Easysoft Ltd, UK
Development



--------sql.log-----------------------

now things look better. However, it seems to appear

[ODBC][17879][__handles.c][421]
             Exit:[SQL_SUCCESS]
                     Environment = 0x82ce7c8
[ODBC][17879][SQLSetEnvAttr.c][182]
             Entry:
                     Environment = 0x82ce7c8
                     Attribute = SQL_ATTR_ODBC_VERSION
                     Value = 0x3
                     StrLen = -6
[ODBC][17879][SQLSetEnvAttr.c][349]
             Exit:[SQL_SUCCESS]
[ODBC][17879][SQLAllocHandle.c][346]
             Entry:
                     Handle Type = 2
                     Input Handle = 0x82ce7c8
[ODBC][17879][SQLAllocHandle.c][464]
             Exit:[SQL_SUCCESS]
                     Output Handle = 0x82ced58
[ODBC][17879][SQLDriverConnect.c][666]
             Entry:
                     Connection = 0x82ced58
                     Window Hdl = (nil)
                     Str In =

[DSN=emanuel-sbart;UID=walter;PWD=***;;UID=;PWD=;][length =


48]
                     Str Out = 0xbfffe020
                     Str Out Max = 2048
                     Str Out Ptr = 0xbfffe01e
                     Completion = 0
             UNICODE Using encoding ASCII 'ISO8859-1' and UNICODE 'UCS-2LE'

DIAG [08001] [SOFTWARE AG][ODBCLIB A][ADABAS]Client unable to establish connection;-715 MISSING USERNAME OR PASSWORD FOR CONNECT.

DIAG [08001] [SOFTWARE AG][ODBCLIB A][ADABAS]Client unable to establish connection;-715 MISSING USERNAME OR PASSWORD FOR CONNECT.

***************his message is repeated about a zillion times*******************
--------------------------------------------------------------------------




Martin
--
Martin J. Evans
Easysoft Ltd, UK
Development


On 22-Feb-2005 Walter Obermiller wrote:


Martin, thanks.

I checked. my unixodbc is indeed threaded.

The driver library however, is not:

 /usr/local/lib/odbclib.so
 /lib/libNoVersion.so.1 => /lib/libNoVersion.so.1 (0x400a9000)
 linux-gate.so.1 =>  (0xffffe000)
 libsqlrte.so => /usr/local/lib/libsqlrte.so (0x400ce000)
 libm.so.6 => /lib/tls/libm.so.6 (0x40109000)
 libc.so.6 => /lib/tls/libc.so.6 (0x4012c000)
 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)


Even with dontDLClose=1 set, I get the dreaded:

 Can't connect to data source DSN=emanuel-sbart;UID=*;PWD=*;, no
 database  driver specified and DBI_DSN env var not set at
 odbc-emanuel-test.pl line 17

message. In particular, do you have any idea how I should interpret the
'no database driver' specified part of the message; is this the result of an earlier failure or does it mean something?



-walt





Quoting Walter Obermiller <[EMAIL PROTECTED]>:




Martin,

thanks for your reply.

as to the version of unixodbc, I use what is part of SuSe 9.2:

  Name        : unixODBC       Relocations: (not relocatable)
      Version     : 2.2.9 Vendor: SUSE LINUX AG, Nuernberg, Germany
  Release     : 4 Build Date: Mo 04 Okt 2004 22:49:44

Is there a way other than recompiling to check whether threading is enabled in this build ?

Try running ldd on libodbc.so and if it mentions pthread library it is probably built with --enable-threads=yes.



Changing the connect string to

my $dbh = DBI->connect('DSN=emanuel-sbart;UID=***;PWD=***;')

      || die "can't connect to $data_source: $DBI::errstr";

as you suggested  results in the message:

  Can't connect to data source DSN=emanuel-sbart;UID=***;PWD=***;,
      no database driver specified and DBI_DSN env var not set at
      odbc-emanuel-test.pl line 17

You asked about the driver I am using:

-----------/etc/unixODBC/odbcinst.ini--------------
[AdabasD]
Description = AdabasD -Treiber
Driver = /usr/local/lib/odbclib.so

this .so is from the adabas11-06 distribution.

-------------/etc/odbc.ini
[emanuel-sbart]
Description = Adabas 11.06 on emanuel
Driver = AdabasD
Server = emanuel
Database = sbart



Try adding DontDLClose=1 to your driver entry in the odbcinst.ini
file. It stop unixODBC calling dlclose. Sometimes drivers install atexit
handlers and once the driver manager has unloaded the .so they are invalid
at exit time.

Martin




Martin Evans wrote:



I might be wrong - my info is well out of date... but on Linux, Perl
built
multithreaded always segfaulted with unixODBC. I think this happened even

if



unixODBC was built threaded (--enable-threads=yes - the default for

unixODBC's



configure but I'd check your unixODBC was built threaded). I can't
remember

the



exact reason I'm afraid. isql is not threaded.

The data source not found message may be related to what DBD::ODBC does.
It first tries to call SQLDriverConnect with (in your case) emanuel-sbart

and



when that fails calls SQLConnect(emanuel-sbart) - you can see this in
your

log.



You can get around this by making the DBI connect string
"DSN=emanuel-sbart;UID=db_user;PWD=db_pass;". See

http://www.easysoft.com/products/9999/faq_answer.phtml?ID=97&product=2002

but it won't make the segfault go away. I'd rebuild your Perl without

threads if



I were you.

You can also see from your log that the SQLConnect succeeeds.

BTW, you did not mention which driver you were using.

Martin

Quoting Walter Obermiller <[EMAIL PROTECTED]>:





Hi, all

I am experiencing a puzzling problem while trying to get an DBD::ODBC connection (via unixODBC) working from a client machine A (Suse linux) to a an ADABAS-D-11 database running on a remote machine (B, also Suse linux)


-------------------------- Machine A (client)
Linux 2.6.8-2
Perl : 5.008005 (i586-linux-thread-multi)
OS : linux (2.6.8.1)
DBI : 1.43
DBD::Proxy : install_driver(Proxy) failed: Can't locate RPC/PlClient.pm in @INC
DBD::ODBC : 1.06
----------------------------------------------



Connections using isql (unixODBC) from machine A to machine B run smoothly, hence I reckon, unixodbc and prima facie odbc-configuration blotches are not the problem.


When I try to trivially connect with DBD::ODBC to the very same DSN that I could connect to using isql without a problem, I get a segmentation fault.

----------trivial-connect----------------------
#!/usr/bin/perl
use DBI;
my $dbh = DBI->connect('dbi:ODBC:emanuel-sbart', '***','***') ||
             die "can't connect to $data_source: $DBI::errstr";
$rc = $dbh->disconnect;
exit();
--------------------------------

and inspection of the sql.log (of unixodbc) reveals the error message:

---------------------
Message Text = [[unixODBC][Driver Manager]Data source name not found, and no default driver specified]
[ODBC][13206][SQLError.c][424]
-------------------------------



Can anybody give me an idea which direction could be pursued to solve this problem ?

What beats me is that isql can connect to my remote database, but an
dbd::odbc connection to the same DSN utterly fails.

Any hints welcome.

 -walter



--------------sql.log----------------------------------------------------
--
--

[ODBC][13206][__handles.c][421]
        Exit:[SQL_SUCCESS]


Environment = 0x82ce928




[ODBC][13206][SQLSetEnvAttr.c][182]
        Entry:


Environment = 0x82ce928






Attribute = SQL_ATTR_ODBC_VERSION






Value = 0x3






StrLen = -6




[ODBC][13206][SQLSetEnvAttr.c][349]
        Exit:[SQL_SUCCESS]
[ODBC][13206][SQLAllocHandle.c][346]
        Entry:


Handle Type = 2






Input Handle = 0x82ce928




[ODBC][13206][SQLAllocHandle.c][464]
        Exit:[SQL_SUCCESS]


Output Handle = 0x82ceeb8




[ODBC][13206][SQLDriverConnect.c][666]
        Entry:


Connection = 0x82ceeb8






Window Hdl = (nil)






Str In = [emanuel-sbart][length = 13]






Str Out = 0xbfffdfc0






Str Out Max = 2048






Str Out Ptr = 0xbfffdfbe






Completion = 0




[ODBC][13206][SQLDriverConnect.c][998]Error: IM002
[ODBC][13206][SQLError.c][424]
        Entry:


Connection = 0x82ceeb8






SQLState = 0xbfffdf60






Native = 0xbfffdd58






Message Text = 0xbfffdd60






Buffer Length = 511






Text Len Ptr = 0xbfffdd5e




[ODBC][13206][SQLError.c][461]
        Exit:[SQL_SUCCESS]


SQLState = IM002






Native = 0xbfffdd58 -> 0






Message Text = [[unixODBC][Driver Manager]Data source name not found,





and no default driver specified]
[ODBC][13206][SQLError.c][424]
        Entry:


Connection = 0x82ceeb8






SQLState = 0xbfffdf60






Native = 0xbfffdd58






Message Text = 0xbfffdd60






Buffer Length = 511






Text Len Ptr = 0xbfffdd5e




[ODBC][13206][SQLError.c][461]
        Exit:[SQL_NO_DATA]
[ODBC][13206][SQLConnect.c][3495]
        Entry:


Connection = 0x82ceeb8






Server Name = [emanuel-sbart][length = 13]






User Name = [walter][length = 6]






Authentication = [***][length = 3]




        UNICODE Using encoding ASCII 'ISO8859-1' and UNICODE 'UCS-2LE'

[ODBC][13206][SQLConnect.c][4069]
        Exit:[SQL_SUCCESS]







Reply via email to