|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #56777 PDO OCI Binding
Submitted: 2006-01-17 04:34 UTC Modified: 2006-03-27 15:53 UTC
From: boshkeev at gmail dot com Assigned: wez (profile)
Status: Closed Package: PDO_OCI (PECL)
PHP Version: 5.1.1 OS: Solaris Sparcle 64bit
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: boshkeev at gmail dot com
New email:
PHP Version: OS:


 [2006-01-17 04:34 UTC] boshkeev at gmail dot com
PDO OCI Binding 
Oracle Database 10g Enterprise Edition Release - 64bit Production
Apache 2.0 is not critical i hope, because even:
oracle@tdk $> php pdo_test.php

All bindning with more than one variable - behaves incorectly. 
I tried in many vays - the same result. I reproduce only one of them.

Reproduce code:
$dbh = new PDO("oci:", "tdk", "12345678"); 
$sql = "SELECT * FROM Region where region_id =:reg_id or region_id =:rg_id"; 
$stmt = $dbh->prepare($sql, array(PDO::CURSOR_SCROLL, PDO::CURSOR_FWDONLY)); 
$stmt->execute(array(':reg_id' => 2,':rg_id'=>1));

Expected result:
the result of the query
SELECT * FROM Region where region_id =2 or region_id =1

Actual result:
the result for the query
SELECT * FROM Region where region_id =1


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2006-02-23 00:21 UTC] cjbj at hotmail dot com
See also which is this problem with the ODBC and DB2 adapters.

I debugged PDO_OCI in PHP 5.1.2.  My testcase was an INSERT statement
with two bound values.

The callback context parameter "param" of the OCIBindDynamic() call at
line 296 of oci_statement.c was the same value for each bind variable.
It should have been different.  Each value should point to its
respective bind variable context.  This context must be valid when
oci_bind_input_cb() is subsequently called at statement execution

The problem stems from pdo/oci_stmt.c.  In my testcase it was
zif_PDOStatement_execute() that allocated param before calling

A fix of COMPLETELY UNKNOWN validity (done by a non-PHP savvy coder,
only quickly tested for the INSERT statement case etc, etc) is:

--- pdo_stmt.c.orig	2006-01-02 07:07:41.000000000 +1100
+++ pdo_stmt.c	2006-02-23 16:10:13.991483512 +1100
@@ -325,14 +325,6 @@
 		return 0;
-	/* tell the driver we just created a parameter */
-	if (stmt->methods->param_hook) {
-		if (!stmt->methods->param_hook(stmt, param,
-			return 0;
-		}
-	}
 	if (param->paramno >= 0) {
 		zend_hash_index_del(hash, param->paramno);
@@ -343,6 +335,14 @@
 		zend_hash_index_update(hash, param->paramno, param, sizeof(*param), (void**)&pparam);
+    /* tell the driver we just created a parameter */
+    if (stmt->methods->param_hook) {
+        if (!stmt->methods->param_hook(stmt, pparam,
+                PDO_PARAM_EVT_ALLOC TSRMLS_CC)) {
+            return 0;
+        }
+    }
 	return 1;
 /* }}} */

Note the change from param to pparam in the ->param_hook() call.
 [2006-03-27 15:53 UTC]
This bug has been fixed in CVS.

In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on

In case this was a website problem, the change will show
up on the website in short time.
Thank you for the report, and for helping us make PECL better.

Thanks for the report, and thanks for the patch Chris.
It wasn't 100% right, but contained enough info to highlight the problem.
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Fri Dec 08 13:01:26 2023 UTC