Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Three things you can do. First, (assuming you are using unixODBC) find your odbcinst.ini file and add:</p> <p>[ODBC] Trace=yes TraceFile=/tmp/unixodbc.log</p> <p>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.</p> <p>Second thing you can do is find where your php executable is and run it under the debugger:</p> <p>gdb /path/to/php</p> <p>When you get the prompt do:</p> <p>r /path/to/my/php_script</p> <p>When it seg faults use the back trace (bt) command to show where it blew up.</p> <p>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.</p> <p>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.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload