php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #40154 bind_param / explode not updating an array as parameters
Submitted: 2007-01-17 14:32 UTC Modified: 2007-01-18 16:05 UTC
From: oliver dot klink at volksbank-rems dot de Assigned: georg (profile)
Status: Not a bug Package: MySQLi related
PHP Version: 5.1.4 OS: Windows Server 2003
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: oliver dot klink at volksbank-rems dot de
New email:
PHP Version: OS:

 

 [2007-01-17 14:32 UTC] oliver dot klink at volksbank-rems dot de
Description:
------------
I try to use mysqli_stmt_bind_param with several elements of an array as parameters. But it seems that these parameters are not updated properly.
In the sample code I initialize the var $data with two values. Otherwise I would get an error saying that the column is not allowed to be null, when I execute the statement.
These start values should be overwritten by the values generated by the explode function. print_r shows that the array $data gets updated as expected while the values transmitted by mysqli_stmt_execute are not.
If I place the mysqli_stmt_bind_param after the explode-command the script works as expected, but I think that's not how mysqli_stmt_bind_param is meant to be used.

Reproduce code:
---------------
<?php
$dw = new mysqli("localhost", "****", "****", "testdb");
$dw->query("CREATE TABLE IF NOT EXISTS `test` (
		`filiale` smallint(5) unsigned NOT NULL,
		`berater` smallint(5) unsigned NOT NULL,
		PRIMARY KEY (`filiale`)
	)");

$data = array(1,2);
$test = array("10;123","20;456");

$stmt = $dw->prepare("INSERT INTO test (filiale, berater) VALUES (?,?)");
$stmt->bind_param("ii",$data[0],$data[1]);

foreach ($test as $buffer) {
	
	$data = explode(";", $buffer);
	print_r($data);

	$stmt->execute();
	echo $dw->error."<br>&nbsp;<br>";
}
$stmt = null;
$dw = null;
?>

Expected result:
----------------
Array ( [0] => 10 [1] => 123 )
 
Array ( [0] => 20 [1] => 456 )

Actual result:
--------------
Array ( [0] => 10 [1] => 123 )
 
Array ( [0] => 20 [1] => 456 ) Duplicate entry '1' for key 1

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-01-18 10:12 UTC] oliver dot klink at volksbank-rems dot de
I checked our PHP Version again and found out we switched back to 5.1.4. But I haven't found any hint in the changelog that this problem is fixed. So I assume it's still there in 5.2.0.
 [2007-01-18 10:25 UTC] tony2001@php.net
So you've bound two elements of the $data array to their placeholders, then you change these elements and re-execute the statement, right?
What makes you think that should magically re-bind the variables?
 [2007-01-18 13:45 UTC] oliver dot klink at volksbank-rems dot de
Well, I think I bind variables, not values. So when I execute a statement it should always use the actual values of the bound variables. If I am wrong, why does it work as expected when I use variables that are not arrays?
 [2007-01-18 14:01 UTC] tony2001@php.net
>If I am wrong, why does it work as expected when I use
> variables that are not arrays?
Because in this case you change the value of the array, not the value of its elements. 
$a = array(1,2); $a = array(2,3); - these are two different arrays, not one array that is being changed.
 [2007-01-18 16:05 UTC] oliver dot klink at volksbank-rems dot de
I understand that you use two different arrays internally and $a holds the pointer to these arrays. But when I use echo $a[0] I always get the value of element 0 of the array $a points to and I think bind should work accordingly. Or at least it should be pointed out in the docs.

Can you suggest a workaround? Should I just rebind the variables each loop or is there a better way?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Dec 22 01:01:30 2024 UTC