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.
One of the many advantages of using a prepared statement, is the ability to bind individual columns in a ResultSet, to named variables. This makes int easier to embed the results in HTML. This is pdo_output.php, which you can find in the Chapter03 03_05 folder of the exercise files. It's exactly the same code as in the prepared statement with named parameter, that was created earlier in this chapter. On lines 11, 12 and 13, we've bound the input values using the bindValue, and the bindParam methods.
To bind the output values, you use the bindColumn method. And normally, you should do that after the prepared statement has been executed. So we execute the prepared statement on line 14. Let's add a new line after there, and call bindColumn on the statement object. The first argument to bindColumn is the column that you want to bind. So let's bind the make column. That's a string that you need to put in there. And the second argument, is the variable that you want to bind the result to.
So we'll simply call it make, beginning with a dollar sign. As well as, using the column name, bindColumn lets you use the column's position in the result, counting from one. So, yearmade is the second result in our result set. So, let's bind that using a number and we'll bind it to year. With PDO, you don't need to bind all of the columns, so let's test this by scrolling down to the table, that displays the results, and replacing the existing values with these new variables, make and year.
So, let's go all the way down, at the moment we're assigning the results to a row, so we're using row make. We change row make simply to make and row year made we can change to year. So if we save that, and test it in a browser, it should work as before. Let's see if we can find some Ford cars. Yes, that's working perfectly. Although you can use the column number instead of the column name, there is a little bit of a problem with it.
Let's go back to the editing program, and I'll show you what I mean. Go right back up to the top, and I'm going to select all of the column names in the SQL. Cut them to my clipboard and replace them with an asterisk, which simply means, select everything from the result. So, if we save that, and go back to the browser, we'll run exactly the same query as before, looking for Ford. And we need to see what happens to this Year column.
So, we click search, and everything has changed too. That's the make iID. What has happened is we're selecting everything from our results, and it's now being presented to us in the same order as it is in the tables, and the cars table begins with car ID, the second column is make ID. Unless you know the order of the columns in the table, using the numbers is rather dangerous. Let's go back and restore those column names, and we'll bind the output values of mileage, price and description to their own variables.
So I'm going to copy this bind column. And paste it there and then duplicate that line twice. Then what we'll do is, we'll have mileage, and we'll make that miles. Then price, price and description, we'll call that desk. Doesn't matter though, I'm still using two up here because we've now got the column names clearly defined, so it will still have the correct value.
So let's go back down to the table, and use these new variables. So, instead of row mileage, we change that to miles. Row price becomes price. And row description becomes desk. Now what we've done, is we've removed the row, the variable that statement fetch was assigning the values to, row equals statement fetch. This will still work, but we're no longer using row, so you can actually get rid of it. You can just use statement fetch on its own.
But then, we have this problem here of what do we have instead of row as our condition? Well the answer is that, as long as you know that we've got a variable that's going to have a value you could use one of those variables. You need to make sure that the variable that you choose, isn't going to have a null value. But in our particular database, all of the columns have got values, so we can just use the first one. We can use make. And then, we can get rid of road down there as well. If we save that. Go back to the browser, and we run this same Ford one again. Everything is working correctly now.
Let's say we create a search for something that doesn't exist. We've got no cars in there, that are called XYZ, search, no results found. So, using one of the bound variables as the condition to determine whether to display the results that works just as well as using the row. Now, I've tested this with both SQLite and MySQL, and it works as you can see here. But with some databases, this won't work.
The results won't be assigned to named variables, but there is a way in which you can solve that problem. And it makes your code far more portable. So let's just go back to the editing program. What you need to do, is you need to pass a PDO constant as an argument to fetch. So that if you put the cursor inside fetch, and it's all in caps, PDO then two colons and FETCH_BOUND. And we need to do that down here as well.
It's not necessary with all databases, but it does make it more portable. So, that's how you bind the values of a column in a result set to a variable. You use the bindColumn method. Just scroll up to the top, and the bindColumn method takes two arguments. The first one is the column that you want to bind. And the second one is the variable that you want to bind the result to. You can use the column number, counting from one. But I regard that as being less safe than using the column name.
Normally, you should call bindColumn after executing the prepared statement. The only exception is when working with large objects in PostgreSQL. A large object in PostgreS, needs to be bound before the prepared statement is executed, but that's the only exception. In this example, I've used the Fetch Method, but it also works with the Fetchall Method.
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.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.