Please help before I go mad

Before I go mad, please tell me why this doesn’t return anything…

<?php

// Version 6.0
// Updated 04 June 2016

// MySQL Connect
include_once('mysqli.inc.php');

// Get Config
function GetConfig($param_name)
{
    $stmt = mysqli_prepare($sql_connect, "SELECT config_value FROM Configuration WHERE config_name = ? LIMIT 1");
    mysqli_stmt_bind_param($stmt, "s", $param_name);
    mysqli_stmt_execute($stmt);
    mysqli_stmt_bind_result($stmt, $return_config_value);
    mysqli_stmt_store_result($stmt);
    mysqli_stmt_fetch($stmt);     
    return $return_config_value;     
}

?>

.

<?php

include_once('functions.inc.php');

echo GetConfig("Test");
  
?>

“Test” exists in the Configuration table but the function returns FA :frowning:

9 Heinekens later, I’ve figured it out, I missed the global $sql_connect :frowning:

3 Likes

Thank you for posting your fix. Too often questions just go unanswered or “solved it”. For future readers who encounter the topic while searching, it’s great to know what you did/didn’t do to fix it so that they will know that your problem has nothing to do with theirs (or is the same!).

3 Likes

But as it’s a function, it would be way better to pass $sql_connect in as a parameter. I know it’s a personal choice, but I have a dislike for functions that make assumptions on the code that’s calling them, in this case that your calling code will have used $sql_connect as the connection object name.

But yes, thanks for updating the post to say how you fixed it.

I’m not sure how passing in $sql_connect as a param would be better?

What are the advantages and disadvantages or this?

It’s really not. Either way that code is going to be a sloppy mess. In order to make real change you need to be using oop. Preferably an active record or mapper pattern.

Passing a param is called dependency injection - meaning that if a function depends on something else (like $sql_connect) that dependency is passed in the param. Of course, the price to pay is having to pass your dependencies but that price is quite small in comparison to the benefit of having the dependencies clear and obvious - you immediately know what the function depends on to do its work properly and this makes it an isolated and reusable piece of code as opposed to using globals, which are not obvious at all and may be different in each project/environment (you don’t know immediately what a global is set to and when and searching for it can be tedious). This becomes important once the project grows or when multiple developers work on it.

Of course, dependency injection is much nicer to use with OOP. For plain functions it is a bit less convenient but I’d say still better than globals.

1 Like

The very case in question is the advantage.

Having it passed as a parameter, you would have been reminded by php about missed function argument.

Also note that raw mysqli is not recommended for the everyday use. Were you using PDO, your code would have been dramatically shorter:

function GetConfig($pdo, $param_name)
{
    $stmt = $pdo->prepare($sql_connect, "SELECT config_value FROM Configuration WHERE config_name = ? LIMIT 1");
    $stmt->execute([$param_name]);
    return $stmt->fetchColumn();
}

Mind the number of queries you need to run

You separated code out into a function, which you generally do because you intend to use that code more than once - not always, but that (to me at least) is the main reason. So every time you call that function, you’ve got to somehow remember that it relies on there being a variable in the calling code with a specific name. Now, if you’ve already written 1500 lines of new code using a different name, then need to add that function, it’s a bit of a pain to have to either change the variable name everywhere else you used it, or have a special version of that function that uses whatever name you’ve picked this time - having re-usable code modules is best if you can re-use them as-is. So if you pass it as a parameter, it doesn’t matter what you call it in the calling code.

Which is pretty much what @lemon_juice said above.

Even for this extremely simple example, the problems with the first should be obvious.

<?php
error_reporting(E_ALL);
ini_set('display_errors', 'true');
$var1 =  3;
$var2 =  5;
function bad_function() {
 global $var1, $var2;
 return $var1 + $var2;
}
$res1 = bad_function();
echo $res1 . '<br>';
function better_function($first, $second) {
 return $first + $second;
}
$res2 = better_function($var1, $var2);
echo $res2 . '<br>';
$var3 = 7;
$res3 = bad_function();
echo $res3 . '<br>';
$res4 = better_function($var1, $var3);
echo $res4 . '<br>';
?>

colshrapnel, while I agree PDO would be the preferred method, it’s object based. I could just about get PDO working with what limited OOP knowledge I have but I’d be mixed PDO OOP with the remaining Procedural Style coding, which isn’t a good idea :confused:

why not - basically all you would be doing would be OO database calls from within procedural code.

If you were using mySQLi then substitution the OO versions of the calls for the procedural ones is just a minor recoding of how the call is done. With PDO all it means is that you have to use the OO version as there isn’t a procedural one.

It makes no difference to the surrounding code whether a particular call is OO or procedural in PHP. In fact starting to substitute OO calls is a good way to get started on gradually converting to using OO code throughout.

2 Likes

That’s just a confusion, a very common one.

You are confusing object oriented programming with object syntax. Although the former is indeed a very complex topic, which only few can master, the latter is just a syntax, which I am sure you already familiar with: it’s not a big deal to add a -> to some variable or a function call.

And regarding mixing object syntax with a procedural one, that’s just an artificial obstacle that you devised out of nowhere. There is nothing wrong with it.

1 Like

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.