Effectively replace the old mysql_result without drastic changes.

[samet5]

How can I effectively replace the old mysql_result? I've read the documentation but it seems I need to change a lot in the old code to make it work again with mysqli_*. Can someone clarify to me what should be done? And explain what is actually different? Your help will be appreciated!

Example 1

function time() {
global $db;
    $sql = "select time from table where id='$id'";
    $result = mysqli_query($db, $sql);
    return mysql_result($result, 0);
}

Example 2

function history() {
global $db;
    $sqlbc = "select count(DISTINCT user_id) from history and time>=DATE_SUB(CURDATE(),INTERVAL 10 MINUTE);";
    $rbc = mysqli_query($db, $sqlbc);
    $ten = mysql_result($rbc, 0, 0);
    mysqli_free_result($rbc);
}

 

Edited October 19, 2022 by samet5

[maxxd]

Neither the mysqli_* nor pdo_* functions are a direct replacement for mysql_*. You're going to have to rewrite code. Advice you didn't ask for; go with PDO. It's much easier to deal with than the MySQLi functions.

[Barand]

Replace

21 minutes ago, samet5 said:

return mysql_result($result, 0);

with
 

$row = $result->fetch_assoc();
return $row['time'];

That second piece of code is beyond help with that query.

[ginerjm]

As suggested - Go With PDO.  Much cleaner and easier not to say more modern even.  You're going to have to replace a lot of statements.  PDO IMO uses fewer statements to achieve the same compatibility.

[mac_gyver]

updating old mysql_ based code requires more than just making it work. you must also make it secure. php's magic_quotes, which provided some protection against sql special characters in string data values from breaking the sql query syntax, which is how sql injection is accomplished, has also been removed. the best choice for updating old application code is to use the PDO extension and use prepared queries when supplying external, unknown, dynamic values to the query when it gets executed.

since you must go through all the database specific code, you might as well future proof it by switching to the much simpler and more modern PDO database extension.

if you use the PDO extension, when you make the connection, set the character set to match your database tables, set the error mode to use exceptions, set emulated prepared queries to false, and set the default fetch mode to assoc. for prepared queries, use simple positional ? place-holders and use implicit binding by supplying an array of input values to the ->execute([...]) call.

[ginerjm]

Agree 99% with mac_gyver.  I like using the named place-holders in queries and then an array of those named values with their true values for the call to execute  as in:

$q = "select fld1, fld2, fld3 where id=:id and age=:age";
$qst = $pdo->prepare($q);

$parms = array(
		':id'=>$currid,
		':age'=>$curr_age
		);
if(!$qst->execute($parms))
{
	(handle the failure of the execute)
}
// continue on with a valid query result

Using named parms makes more sense when looking at the code weeks or months later as well as they help when modifying your code and not having to figure out those ?? later.

PS - when building and using prepared queries here is the idea behind them.   One writes a query statement, as in $q above, and then prepares it which readies the sql code for later execution.   Now that prepared statement, represented above by $qst, can be run multiple times b simply altering the parms array and calling execute.  Not something that is done all the time but when the need arises it is more efficient.  Of course most of the time you are just doing it to protect your database from hackers providing bad input values and your code not properly validating them.  You should do that validating but this way the prepare process goes further to ensure that you don't end up running a dangerous query statement.

Edited October 19, 2022 by ginerjm