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
