Pervasive SQL Driver

Question

UPDATE: should be on serverfault as suggested. New post here: https://serverfault.com/questions/451220/psql-64bit-driver-error

I am having a hard time getting PHP to connect with ODBC using a Pervasive SQL driver.

I have an Ubuntu Server 12.04 and have installed the 64bit PSQL Client drivers from here: http://www.pervasivedb.com/psqlv11/Pages/PSQL-v11-Linux-Downloads.aspx

I have setup my ODBC.ini with the DSN to my database, and I can happily connect and then run queries:

isql Exchequer

When I use PHP, odbc_connect looks OK and gives me a resource, but odbc_exec (the point at which the driver is called) then totally fails (SEG fault):

[Fri Aug 10 11:05:50 2012] [notice] child pid 13770 exit signal Segmentation fault (11)

What am I doing wrong?

UPDATE:

Here is the output from gdb

(gdb) run /var/www/default/scripts/stock/index.php
Starting program: /usr/bin/php5 /var/www/default/scripts/stock/index.php
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffecc89700 (LWP 14514)]
[Thread 0x7fffecc89700 (LWP 14514) exited]
Halt[Inferior 1 (process 14513) exited normally]
(gdb) bt
No stack.

And the PHP error.log entry

[Fri Aug 10 15:24:53 2012] [notice] child pid 14510 exit signal Segmentation fault (11)

I also added in the Trace/TraceFile but I don't seem to get any output saved to the log file.

Update 2:

This is the simplified script I am running:

if(!$odbc = odbc_connect("exchequer","username","password")) { die("Connection to Exchequer failed"); } $rows = odbc_exec($odbc,'SELECT sl.slStockCode, sl.slQtyInStock, sl.slQtyAllocated , sl.slLocCode FROM StockLocation sl WHERE sl.slLocCode IN (\'DIG\',\'WOO\',\'MEN\')'); echo "

".print_r($rows,true)."

";

The odbc_connect works (doesn't die) but I keep seeing error 342 in my browser, and "exit signal Segmentation fault" in the apache log files.

bohica bohica · Accepted Answer · 2012-08-10T10:23:36

It could just be a bug in one of the components you are using but my best guess it is a mismatch in your components for the size of SQLLEN/SQLULEN when they were compiled. You can enable logging in unixODBC and it may give us a hint. Edit your odbcinst.ini file and add the following to the top:

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

If you don't know which odbcinst.ini file you need to edit run odbcinst -j and it will tell you. Now run your PHP script and the file above should contain the log.

Or, you could run php under the debugger (gdb) and see where it falls over. For this you'll need to find where your php executable is and run something like:

gdb /path/to/php

then type "run /path/to/my/php/script" and when it falls over type "bt" to get a back trace which will tell us where it fell over.

However, if it is a SQLLEN/SQLULEN mismatch corruption is probably going on and that can mean it seg faults somewhere totally different from where the problem is. You need to verify that PHP's ODBC module, unixODBC and your ODBC driver were all built with SQLLEN and SQLULEN the same size. I'm guessing if you installed unixODBC and PHP from Ubuntu then they will match and so the odd one out will be the Pervasive driver for which you'll need to ask them.

odbcinst -j outputs the size of SQLLEN/SQLULEN that unixODBC was built using.

You can find a lot more about this at 64-bit ODBC

Pervasive SQL Driver

1 Answers