php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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 Developer Edit
 [2006-01-17 04:34 UTC] boshkeev at gmail dot com 
Description:
------------
PDO OCI Binding 
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 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

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-02-23 00:21 UTC] cjbj at hotmail dot com 
See also http://bugs.php.net/bug.php?id=35671 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
time.

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

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,
-				PDO_PARAM_EVT_ALLOC TSRMLS_CC)) {
-			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] wez@php.net 
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 pecl.php.net.

In case this was a pecl.php.net 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-2025 The PHP Group
All rights reserved. 		Last updated: Tue Apr 22 04:01:26 2025 UTC