The database management system Sybase ASE supports multiple result sets, however the implementation of Sybase in PHP doesn't. There is a bug reported on this issue and there is also a patch supplied in that report (https://bugs.php.net/bug.php?id=48675). The patch is for version 5.2.9 and I've tried to add it to version 5.3.10. The source builds without warnings or errors, and testing the new function 'sybase_next_result()' does not yield a fatal error "Call to undefined function". This would suggest that the function is implemented, but not working as expected.
Configuration is:
configure --disable-isapi --enable-debug-pack --without-mssql --without-pdo-mssql --without-pi3web --with-mcrypt=static --disable-static-analyze --enable-cli --with-sybase-ct=%SYBASE%\%SYBASE_OCS%
There is a notice on 'sybase_query()' when there are multiple result sets saying "Sybase: Unexpected results, cancelling current in...". The first result set is retrieved. And this notice is returned even without the patch.
The number of stored procedures in the database that return multiple result sets is vast, and a 'sybase_next_result()' would be the best solution. In short, I looking for an equivalent to 'mssql_next_result()' (http://se2.php.net/manual/en/function.mssql-execute.php) for Sybase in PHP 5.3.10.
Worth noting is that the other parts of the Sybase implementation is in place and seems work as expected.
My testing environment is a WAMP server (Windows 7, Apache 2.21, MySQL 5.5.20, PHP 5.3.10) and Sybase ASE is version 15.7.0.
Is there anyone out there that has "solved" this?
With regards
//Jonas
Update:
A colleague gave me the instructions to use 'OutputDebugString()' (http://msdn.microsoft.com/en-us/library/windows/desktop/aa363362(v=vs.85).aspx) and catch that with DebugView (http://technet.microsoft.com/en-us/sysinternals/bb896647).
From this I can say that 'sybase_next_result()' is called but the block
if (sybase_ptr->active_result_index) {
...
}
is not run. This is probably correct (as I see it).
The row
retcode = ct_results(sybase_ptr->cmd, &restype);
is always setting 'retcode' to 'CS_FAIL'. This is perhaps because the earlier
ZEND_FETCH_RESOURCE2(sybase_ptr, sybase_link *, sybase_link_index, id, "Sybase-Link", le_link, le_plink);
sets 'sybase_ptr' in sutch fashion that 'retcode' becomes 'CS_FAIL'.
Related
I am currently building a database handler. Running on PHP 5.4.16 on top of a Firebird database.
When I have made a prepared statement, I need to execute the SQL with the arguments. I made this function:
private function assignParameters($args)
{
return call_user_func_array('ibase_execute',$args);
}
The problem is when I make an error in the args (not giving it the values that are expected), I expect the return to give false(error). ibase_execute normally returns false when an error has occurred.
But right now my PHP installation(XAMPP) simply crashes and restarts. I have tried using a try/catch without any luck. The call_user_func_array doesn't fail but I would expect it to return the result from the ibase_execute. I'm confused.
I should mention that there are no entries in PHP/Apache error logs. The only entry is that the Apache2 server have restarted.
The interbase configuration from phpinfo();
Firebird/InterBase Support dynamic
Compile-time Client Library Version Firebird API version 25
Run-time Client Library Version WI-V6.3.2.26539 Firebird 2.5
Any ideas - is this the driver crashing?
EDIT:
As requested from Mariuz here is what I got from the debug at crash time. The crash creates two dump report from the http process witch is running the PHP code.
They both contain a lot of information. To much to dump here but here's the excetions.
Dump 1
Exception Information
In httpd__PID__10168__Date__02_21_2014__Time_03_40_11PM__949__Second_Chance_Exception_C0000008.dmp the assembly instruction at 0x76ed12c7 which does not correspond to any known native module in the process has caused an unknown exception (0xc0000008) on thread 0
Dump 2
Exception Information
MSVCR80!UNWINDUPVEC+50In httpd__PID__10064__Date__02_21_2014__Time_03_40_05PM__321__Second_Chance_Exception_C0000005.dmp the assembly instruction at msvcr80!UnwindUpVec+50 in C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6195_none_d09154e044272b9a\msvcr80.dll from Microsoft Corporation has caused an access violation exception (0xC0000005) when trying to read from memory location 0x00000000 on thread 5
This seems to be a segfault in php please provide the script and a backtrace to it
https://bugs.php.net/bugs-generating-backtrace-win32.php
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!
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
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.
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...
After 2 days battling, I try asking help here. I'm using unixODBC (2.2.11) to work with DB2 (iSeries) and PHP (5.3) on a CentOS 5.4 server. I guess it's since the upgrade of PHP from 5.1 to 5.3, I get PHP to segfault on certain queries. After some investigation, I discovered the problem appears on some queries with long char fields, for example with this table :
TABLE (
CONTRACTID NUMERIC,
SOMETEXT CHAR(583)
)
This simple piece of code provokes the segfault :
try {
$conn = new PDO("odbc:".$dsn, $username, $password, array(
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION)
);
}
catch (Exception $e) {
echo $e->getMessage();
}
$sql = 'SELECT * FROM LIB.TABLE ';
$stmt = $conn->prepare($sql);
$vals = $stmt->execute();
$rows = $stmt->fetchAll(PDO::FETCH_ASSOC);
Is there any column length limit or a bug with unixODBC and/or PHP >= 5.1 ?
This web application worked quite great, then I got into this problem..
Btw, I tested with a more up-to-date 64bits CentOS 6.2 machine with unixODBC 2.2.14 and PHP 5.3, and the problem is the same.
Any help greatly appreciated,
Thanks
fabien
UPDATE :
Using the PHP odbc functions, it works :
$conn = odbc_connect($dsn, $username, $password);
$res = odbc_exec($conn, $sql);
$rows = odbc_fetch_array($res);
So the problem is more tied to PDO, any idea?
Ran into the same problem here. Found that the 64-bit php-odbc module is causing the seg fault when returning a field with a NULL value. A workaround is to coalesce each field in which a NULL value could exist. It's not a good solution. I'm looking at the php-odbc.c code, but I can't guarantee a fix.
Workaround:
SELECT COALESCE(CHAR(fieldname),'') FROM ...
I think I'm going to replace this server with a 32-bit version. I have others that work just fine.
I had a similar problem on Centos 6.3 with Vertica 6 and the UnixODBC that comes with Centos, PHP would just segfault. So I ran strace php mytest.php and found that it tried to find and open /usr/lib64/libodbccr.so.1
However Centos 6.3 only has libodbccr.so.2
So the quick and dirty fix is to do the following in: /usr/lib64
ln -s libodbccr.so.2 libodbccr.so.1
Use at your own risk!
I cannot say I know of any issues in pdo (which I don't use anyway) or unixODBC or the DB2 driver. I'm not sure from your email if your first platform is using 64 bit builds or 32 bit builds but ODBC changed when Microsoft added 64 bit support (see SQLLEN/SQLULEN and 32/64 bit platforms and 64-bit ODBC). Basically, some ODBC APIs had a type changed from SQLINTEGER to SQLLEN and an SQLLEN is 64bits in a 64 bit build and 32 bits in a 32 bit build. However, as no one was to know Microsoft was going to do this and some of these arguments were actually described in the spec as 32 bit quantities some ODBC driver writers had already built ODBC drivers for 64 bit platforms using 32 bit quantities for these arguments. Obviously, if you mix an application or driver manager built one way with a driver built the other way all hell can break lose and you very well may get segfaults. So, firstly, if you are using 64 bit binaries you need to check your ODBC driver was built correctly - speak to IBM.
unixODBC 2.2.11 is rather old now and I know issues have been fixed but I'm still using it extensively and only have one small issue in the cursor library. Anyway, you tried 2.2.14 and the problem was the same. I doubt it is an unixODBC issue but that is only based on my extensive experience with it and not because I know for a fact.
Now, assuming you don't fall into the situation outlined above you can do a number of things. Try enabling logging in unixODBC then you can see what ODBC calls are being made and which one fails. You might also get a clue from the arguments passed as to what might be going on. You enable logging by adding the following to your odbcinst.ini file:
[ODBC]
Trace=yes
TraceFile=/tmp/unixodbc.log
Look for a call to SQLBindCol or SQLGetData for the column in question. If this does not get you anywhere you can try pasting the end of it here and I'll look at it.
If you can run your PHP program from the command line and you install gdb you can run it under gdb and it will show you a stack dump of where the problem occurred. Just do gdb /path/to/php then type r myscript.php and enter to run it and when it segfaults you can use the bt (backtrace) command to show the stack. That should identify which code is causing the segfault although it is not necessarily that code which is fault (e.g., if php passed a pointer to a buffer of 10 bytes but lies and says it is 100 bytes the code which writes off the end is not at fault).
I inherited an old Cakephp site that was using adodb as a driver to connect to an MSSQL database and it turns out this is no longer supported in the new version of cake (1.3, we are in 1.2) so I'm trying to change the driver so I can upgrade. We're using IIS and a sql server 2005 database on a different server, php 5.2.17. However using driver "mssql" gives me the following errors:
PHP SQL Server interface is not installed. For troubleshooting information, see http://php.net/mssql/
Call to undefined function mssql_min_message_severity()
The top error leads me to a page regarding the old php_mssql.dll, which according to this question: ( CakePHP: error when trying to use mssql datasource ) will become a problem when I switch to PHP 5.3 so I'm trying to use the php_sqlsrv*.dll for my php version but I still get the error. Could never get the mssql.dll one to work either. I do however see "sqlsrv support enable" in phpinfo.php and the whole sqlsrv section is intact there.
In cake php I'm using "driver => 'mssql'", is this the correct driver for the new sqlsrv dll? Is there something I'm missing? For kicks I tried 'driver' => 'sqlsrv', that fixes the php SQL Server interface error but I still get
"Fatal error: Call to undefined function sqlsrv_min_message_severity() in C:\Inetpub\wwwroot\riverstone-dev\www\cake\libs\model\datasources\dbo\dbo_sqlsrv.php on line 107"
Installing the latest SQL Native Client set from Microsoft and reenabling the extension in PHP has worked, albeit on a different server. Please try the drivers below if having a similar problem:
http://www.microsoft.com/download/en/details.aspx?id=20098
i am using sqlite_escape_string($str) to prepare sql statements for future use.
however, when i migrated my code to a new server, it says:
Call to undefined function sqlite_escape_string()
seems the Sqlite and everything is working in the new server, but i have error even for a sqlite_open().
Anyways, i just need to escape my $str to a sqlite safe sql statments, i dun even need to write to sqlite from PHP, so an
That sounds like the SQLite plugin is not enabled for PHP. Write <?=phpinfo()?> in a .php file, load it up on your server and see if SQLite is mentioned in the loaded plugins.
You need to uncomment the extension=php_sqlite.dll line by removing the semi colon right now your pdo_sqlite is enabled and sqlite_escape_string is a function of sqlite extension and sqlite_pdo will not work untill php_sqlite is enabled
I found the ans myself.
It is due to my server is a Centos 5.4, and sqlite support for php is not there.
The same case should exist in REL5 also.
see the 1st and 2nd latest comment in the link below:
http://www.php.net/manual/en/sqlite.installation.php
I solved it by recompiling my php and added the sqlite.ini file
For those who recently upgraded to 5.4+, note that the php docs say, this method is not available 5.4+
(PHP 5 < 5.4.0, PECL sqlite >= 1.0.0)
So you would either need to manually compile it in, or look at PECL.