On 15/08/12 15:32, Jeff Tate wrote:
> Couldn't find odbcinst. Compiled test code as instructed. Result of a.outOk, so this /should be/ good. It means that compiling DBD::ODBC with those header files means SQLLEN and SQLULEN are 8 bytes in size and one /would hope/ if teradata was compiled the same way it was also using SQLLEN/SQLULEN of 8 bytes. If this is the case my guess is wrong.
> size of SQLLEN is 8
BTW, I spoke to lead developer for unixODBC and he thinks the ODBC driver manager that comes with teradata might actually be unixODBC as he had some contact with teradata some time ago.
If above is correct you should not need to install unixODBC separately.
> As for decision to install Teradata odbc rather than SUSE odbc, that was
So, the problem remains why is this segfaulting - it gets harder now. I'm kind of tempted to say "ask teradata" but I'll try and give you some suggestions so we might try and track it down.
t/03dbatt.t was the first test to fail so we'll start with this one. Assuming it is unixODBC you are using edit your odbcinst.ini file (/opt/teradata/client/ODBC_64/odbcinst.ini assuming you still have ODBCINSTINI set as in your first post) and at the top add:
Now go to the dir where you are building and running DBD::ODBC test suite and do:
prove -vb t/03dbatt.t
If you are using unixODBC it should write something to /tmp/unixodbc.log. If it does post the last 100 lines.
which should output something like:
then assuming you have gdb (or install it) do:
gdb /usr/bin/perl <---- replace with which output
and at the prompt do:
run -Iblib/lib -Iblib/arch t/03dbatt.t
when it crashes type "bt" for a back trace and post it.
Even if we cannot get a clue from this it will be useful if you go to teradata.
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.