Is there a way to get a result object from a prepared statement? Using $stmt->bind_result() isn't possible in the case of the application I'm trying to write as I don't know the query in advance. It seems like a pretty dumb idea altogether, come to think of it.
There is no way natively to do this, I think you are probably talking about the equalivant to mysql_fetch_object() for mysqli.
I too have run into the problem you are having, and got around it by this:
class clsDB extends mysqli {
[ ... constructor/connection stuff here ]
public function getResultParams($objST) { $objRes = $objST->result_metadata(); while ($field = $objRes->fetch_field()) { $arrayReturn[] = "\$res" . $field->name . ""; } $strReturn = implode(",",$arrayReturn); return $strReturn;
} }
$objDB = new clsDB(); $objStmt = $objDB->prepare("SELECT column1,some_other_column from table"); $objStmt->execute(); $strResParams = getResultParams($objStmt); $strEvalCode = '$objStmt->bind_result('. $strResParams .');'; eval($strEvalCode); $objStmt->fetch(); // result stored in vars prefixed by "res": $rescolumn1, $ressome_other_column ?>
Now this method uses eval, and quite certainly you could easily mod the code above to store the values into an instance of stdClass...but back to the eval. I know historically a lot of people have dubbed eval a "slow" operation that should be avoided.
While I tend to agree with the avoided part, the "slow" part is just plain rubbish. There have been numerous benchmarks under the comments section of the eval function:
And none have shown "slower" PHP scripts because of the use of eval. Albeit with one exception, Windows and mod_php. Spawning processes in a *nix system is much less resource intensive than in Windows. IIRC, eval() calls result in a new PHP process being spawned. Again, even in Windows, the extra load time is mostly irrelevant.
Using the above code to get an result object instead of just variables:
Thanks for your quick reply. I tried using eval(), and even call_user_func_array() but couldn't get a sensible result from either of them. Your code looks neat enough, and like you said, performance considerations with eval() are irrelevant.
I got around this by using PEAR::DB instead. A problem I have now is that prepared statements don't work when using LIKE. So, SELECT blah FROM table WHERE blah LIKE '?%' causes all sorts of mayhem. I don't know if this is a limitation of PEAR::DB or just prepared statements in general. Is mysqli able to handle this case?
You may do so by binding the wildcard in the actual variable:
$blah = new mysqli(); $stmt = $blah->prepare("SELECT * FROM test where ID LIKE ?"); $null = 9 . "%"; // Put wildcard in here $stmt->bind_param("s",$null); $stmt->execute(); $stmt->bind_result($b,$c); while($stmt->fetch()) { echo "$b <br />"; // will print all ids that start with 9
}
Excuse my variable naming, just did a rough copy from a test script.
Regards
On 11/22/05, nood...@gmail.com <nood...@gmail.com> wrote:
> Thanks for your quick reply. I tried using eval(), and even > call_user_func_array() but couldn't get a sensible result from either > of them. Your code looks neat enough, and like you said, performance > considerations with eval() are irrelevant.
> I got around this by using PEAR::DB instead. A problem I have now is > that prepared statements don't work when using LIKE. So, > SELECT blah FROM table WHERE blah LIKE '?%' > causes all sorts of mayhem. I don't know if this is a limitation of > PEAR::DB or just prepared statements in general. Is mysqli able to > handle this case?
Your solution looks fine for situations where the query is known in advance, but like the original case, doesn't neatly handle a generic query implementation. Hopefully mysqli will address these issues as it matures.
I don't understand. You only need to know how the wildcard will be used in advance, not the query. Am I missing something?
Regards
On 11/23/05, nood...@gmail.com <nood...@gmail.com> wrote:
> Thanks again John.
> Your solution looks fine for situations where the query is known in > advance, but like the original case, doesn't neatly handle a generic > query implementation. Hopefully mysqli will address these issues as it > matures.
