CODEWITHSUNDEEP
phpodbcteradata
Craig Oley
Craig Oley

Reputation: 41

PHP odbc_exec Segmentation Fault after successful odbc_connect to Teradata 14.0

I am using PHP 5.3.3 on RHEL 5. I have installed all the necessary drivers and add-ons for ODBC connections to Teradata. I wrote a simple script to test it:

$con_string = "DRIVER={Teradata};DBCName=**HOST**; DATABASE=**database**;";
$con = odbc_pconnect( $con_string , "user", "pass" );
var_dump($con);
echo 'here';
$res = odbc_exec($con, "SELECT id FROM database.table");
echo 'there';
var_dump($res);

The output is as follows:

resource(5) of type (odbc link persistent)

hereSegmentation fault

Obviously the connection works. I have also tried other commands, some work, some don't. odbc_tables() and odbc_procedures() return the correct information without problem. However, anything related to a SQL query gets a seg fault. I have not been able to get trace/debug to turn on for ODBC.

Any help would be greatly appreciated!

Upvotes: 3

Views: 2818

Answers (3)

BobFlemming
BobFlemming

Reputation: 1

I have seen this issue previously (specifically with Teradata ODBC connectivity) and remember having to patch and build a custom PHP executable in order to get it to work. I'm light on the details as it was some time ago but remember its due to a problem with PHP's ODBC_pconnect and the TD drivers. It seems that PHP's odbc_connect also uses odbc_pconnect so never worked - once odbc_connect was patched to remove odbc_pconnect I could use PHP as expected.

Sorry if that's a rambling mess, hopefully it will give you some pointers...

Upvotes: 0

Stephan van Ingen
Stephan van Ingen

Reputation: 51

I experienced this problem with using a resultset twice for two different odbc_exec's. It was resolved doing unset($res) before each odbc_exec so the odbc_exec always starts using a clean variable.

I don't yet have a good explanation 'why' (probably previous resultset variables require correct 'closes'...?), but this prevents my segmentation faults

Upvotes: 2

bohica
bohica

Reputation: 5990

Three things you can do. First, (assuming you are using unixODBC) find your odbcinst.ini file and add:

[ODBC] Trace=yes TraceFile=/tmp/unixodbc.log

Run your PHP script from the command line and you should get a log. If it is segfaulting in unixODBC or your ODBC driver the last line should show an entry into an ODBC API but no exit. However, that will only give you a clue as to where it is failing.

Second thing you can do is find where your php executable is and run it under the debugger:

gdb /path/to/php

When you get the prompt do:

r /path/to/my/php_script

When it seg faults use the back trace (bt) command to show where it blew up.

Lastly, you could have a teradata ODBC driver which was not built with the same ODBC headers or defines as PHP and unixODBC. This is very tricky to discover but if you are on a 64 bit machine it is a possibility. You can use unixODBC's odbc_config command to find out how unixODBC was built. In particular odbc_config --ulen and --cflags. Unfortunately most debian based distributions don't include odbc_config yet - may be you'll be luckier on redhat. The thing you are looking for is teradata being built with SQLULEN 32 bits and unixODBC/PHP with it 64 bits - if you've got this situation you'll definitely get segfaults. If this is your issue you need to get the correct build from teradata or switch everything to 32 bit binaries.

Armed with this info you might be able to find out what is going wrong. You can always post the gdb back trace or the end of the unixODBC log file and I may be able to help.

Upvotes: 0

Related Questions