Couldn't find odbcinst. Compiled test code as instructed. Result of a.out is:
size of SQLLEN is 8 As for decision to install Teradata odbc rather than SUSE odbc, that was made by the sysadmin team. I am just a user. I will however ask them if there is the possibility to install unixodbc - is that target neutral or is there some additional work they would have to do to enable a Teradata connection. Thanx -----Original Message----- From: Martin J. Evans [mailto:martin.ev...@easysoft.com] Sent: Wednesday, August 15, 2012 4:06 AM To: Jeff Tate Cc: dbi-users@perl.org Subject: Re: Help please with DBD::ODBC on SUSE-Linux On 14/08/12 19:05, Jeff Tate wrote: > I am trying to build a private perl with ODBC connection to a Teradata > database on SUSE-Linux. Perl build with no errors, DBI installed > clean, DBD::ODBC compiles seemingly cleanly, but fails almost all the > tests. So, help will be gratefully accepted. > > The attached shows: > > .Relevant environment Out of interest, why did you choose to use the ODBC driver manager in /opt//teradata/client/ODBC_64 instead of unixODBC installed from a suse package? > .Results of ODBC adhoc connect test > > oSuccessful > > oDeliberately not successful, as it shows driver identification tags > > .cpan results > > oget > > omake > > otest > > I installed CPAN::Reporter, so I expect (though am not sure as this is > new to me) that reports have been posted. > Thanx in advance for any and all insights (per the admonition, I > looked for a README.linux to review, but there wasn't one) > > Jeff Tate So running make test results in a segfault. You have a 64 bit machine and from the names of the dirs where teradata is installed I'm guessing it too is 64 bit shared objects. However, there is nothing in the c compilation which sets the size of SQLLEN and SQLULEN which are /usually/ 64 bits on 64 bit linux and 32 bits on 32 bit linux. If DBD::ODBC was built with 32 bit SQLLEN/SQLULEN and teradata and the driver manager were built with 64 bit SQLLEN/SQLULEN I can well imagine it would end up seg faulting - this is my guess. Does the /opt/teradata tree contain an odbcinst binary? If it does run /path/odbcinst -j and post the output. If it does not, compile and run the following C code and post the output: put the following in x.c file: #include <stdio.h> #include <sql.h> main() { printf("size of SQLLEN is %d\n", sizeof(SQLLEN)); } compile with: cc -I/opt/teradata/client/ODBC_64/include x.c run with ./a.out What does it output? The background is that MS changed the ODBC spec when they released 64 bit windows and changed some ODBC APIs to use SQLLEN/SQLULEN when before they used SQLINTEGER/SQLUINTEGER. The former are 32/64 bit depending on architecture and the later are always 32 bit. Before they did this 64 bit Unix existed for ages and stuck to the existing API which was using SQLINTEGERs. This led to confusion and situations like I expect you've hit. Basically, DBD::ODBC needs to know the size of SQLLEN and it normally does this by running: odbc_config --cflags -DHAVE_UNISTD_H -DHAVE_PWD_H -DHAVE_SYS_TYPES_H -DHAVE_LONG_LONG -DSIZEOF_LONG_INT=4 -I/home/martin/unixODBC-2.3.1/include and adding those flags to the cc line (note the above came from a 32bit machine). However, I cannot know you are really using unixODBC as I've no idea what came with teradata in those dirs. Martin -- Martin J. Evans Easysoft Limited <http://www.easysoft.com> http://www.easysoft.com
