Strugling with 'Fatal error: Call to a member function prepare() on a non-object in..'

Hi folks,

Banging head with this error. Please help.

Fatal error: Call to a member function prepare() on a non-object in

function get_branch_name($branch_id,$company_id){
    $query="SELECT * 
            FROM branches
            WHERE branch_id=:branch_id
            AND company_id=:company_id" ;

    $stmt = $db->prepare($query);
    $stmt->execute(array(':branch_id' => $branch_id,':company_id' => $company_id));
    $row = $result->fetch();
    return $branch_name;

This function is called from another script where it has db connection correctly declared on the header.


but still this error appearing :frowning:

1 Like

Thanks folks,
finally found the solution.
passing the db as a paramerter helped.

function get_branch_name($branch_id,$company_id,$db){


Yeap, that usually helps :slight_smile:

While I’m not the biggest fan of the global statement because of the spaghetti code it helps create, this is the sort of situation it is meant for.

function get_branch_name($branch_id, $company_id) {
  global $db;
  // rest of code here

But a better solution would be to make a model class that groups this function along with similar functions dealing with the branches table. That class would receive db as a construction argument

class BranchModel {
  private $db;
  public function __construct( PDO $db) {
    $this->db = $db;

Then this method could refer to it like this.

  public function getBranchName ($branch_id, $company_id) {
    $stmt = $this->db-prepare($query);
    // and so on

The outside code would have you make an instance then pull it…

$branches = new BranchModel($db);
$branchName = $branches->getBranchName($branch_id, $company_id);

If your code has a dependency management system it can handle the attachment of the $db object to the model.

This is provided as a relevant example to the code you’re working on now as to how and why classes are used.

Just because you’ll see examples of
global $db;
*cough* WordPress *cough*
doesn’t mean it’s best practice

I’m not going to argue the merits of the global statement over proper architecture for the code, that’s a losing proposition. I was just stating that this is the situation the statement was created for back in the days of PHP 3, before any OOP model was introduced to the language (or at least I think class only dates back to PHP 4). WordPress is the way it is because it dates back almost that far and trying to do anything now breaks thousands of plug ins. Of course, eventually, that slavery to backwards compatibility will prevent wordpress from moving forward - it already falling behind Drupal 8 in underlying architecture and its only lead is in interface usability and stability.

That’s also why I provided the Object Oriented model. If this is a new project I’d recommend moving into an OO model now while its relatively easy. If this a maintenance patch on an old codebase global might make more sense, especially if $db is global in the scopes of other functions.

As I know Mittinleague knows, but for the sake of those who don’t, the main reason global is avoided is the code it creates is more difficult to test in PHP unit and similar suites. Strictly speaking, functions shouldn’t have internal state - given x input they should always return y and further they should never change the outside program state (although a method of a class may operate on a member, as setter methods do) .

The global keyword merely brings the variable into scope. It doesn’t place any restrictions on modifications to that variable. If you use the keyword (not recommended) you should at least take care to never, ever, change the value of any variable brought into the function in this way. If you need to change a variable’s value take it in as an argument, even if you do so by reference the maintenance programmer who comes after you (which may be yourself) can at least look at the function call and see what variables may change.

Best practice is to not use receive by reference and allow the function’s return to be its only communication to the outside world. Also, as can be inferred from my prior post, if you have a group of functions that all need the same argument variable it may be best to bind them together into a class.

If it’s part of an old codebase you might want to consider writing a new up to date codebase from scratch and only do security fixes for the old codebase

I suggest you to build a class for database connection, then use inheritance to make things easier.

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