Viewers: in countries Watching now:
Now that PHP has true object-oriented capabilities, it's best practice to access databases using PDO (PHP Data Objects) and MySQLi. These methods produce database-neutral code that works with over a dozen systems, including MySQL, SQL Server, PostgreSQL, and SQLite. Learn how to use PDO and MySQLi to perform basic select, insert, update, and delete operations; improve security with prepared statements; and use transactions to execute multiple queries simultaneously. Author David Powers also covers advanced topics like instantiating custom objects, and compares PDO to MySQLi so you can decide which method is right for you.
In the previous video, we created a transaction to transfer money from one account to another But there was nothing to prevent the transaction from going ahead if the payer ran out of funds. This is mysqli_check_balance.php, which you can find in the chapter six, 06_05 folder of the exercise files. This updates the previous script to roll back the transaction if the balance in the outgoing account falls below zero.
But adding in this extra step results in MySQLi generating a fatal error. Before examining the code, let's take a look at the error message by loading the page into a browser. It says that the fatal error is a call to a member function fetch_assoc on a non-object on line 83. So let's examine the code to see what's happening on line 83. We need to go all the way down to the bottom of the page, and line 83 is the beginning of the while loop that displays the balances.
And that balances query is executed here on line 59. And it's got nothing to do with the transaction or with rolling back the transaction if there are insufficient resources. So let's go back to the top of the page to see what the new code does and see if we can find the cause of this fatal error. On line 10, there's a new select query that checks the payer's balance. And lines 19 to 23 initialize a statement called check and bind payer to the question mark placeholder in the new select query, declaring its status type to be a string. And the new prepared statement is executed down here on line 40. On the following line, the result is bound to a variable called bal and then fetched. And if bal is less than 0, this conditional statement on lines 45 to 48 rolls back the transaction and sets an appropriate error message. The rest of the transaction is inside the else block down here. All this looks fairly straightforward, but as we've seen, executing this new prepared statement causes the script to collapse like a house of cards.
To debug the issue, I first used echo to display the value of bal, and that worked okay. So the next thing I have to look at was the receive statement, and receive is executed here on line 49. So to find out if there's a problem, let's use the receive statement's error property to find out what's going on. So we'll use echo and receive and its error property. So if we save that, go back to the browser, and refresh, we've now got this error message, Commands out of sync, you can't run this command now.
Basically, the problem is that MySQLi thinks there might be more results in the check statement and it won't run any further statements or queries until we store the results or close the statement. So let's just go back to the code. We've already bound the result to the variable bal and then fetched it. So there's no need to call the storeResult method. We've already got the value that we want. So let's close the statement to free up the resources required by MySQL. So, it's the check statement object and we just call its close method.
And that destroys the statement object and frees up all the resources connected with it. So let's just save the page and go back to the browser. And if we reload the page, all the error messages have gone away and John White's balance has been reduced to $600. So, if we continue reloading, down to 400, 200, getting dangerously close, 0. Reload again. Transaction failed. Insufficient funds in John White's account. So, closing that prepared statement when it was no longer needed solved the problem.
And although the other two prepared statements aren't causing problems, it's recommended that you close all statements explicitly when they're no longer needed. So let's go and fix that. And also, we don't need to display the error message from receive because there is no message now, so scroll down to the bottom. And then after the transaction, we've got two prepared statements. The first one is pay. We need to close that, and also close receive.
MySQL is very fussy about trying to run another query when there might still be unused results that haven't been stored in PHP memory. In other words, unbuffered results. To prevent this happening with prepared statements, it's a good idea to call the close method on a statement as soon as it's no longer needed. And in the next chapter, we'll take a look at the difference between buffered and unbuffered results and other situations where you might get the commands out of sync error.
There are currently no FAQs about Accessing Databases with Object-Oriented PHP.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.