"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Yes, I am aware that the fetch_object() in mysqli will call the constructor AFTER it reads data into the object. I am primarily using PDO in my application, but I do mysqli counterparts of all my DB calls for practice.

As for mysqli_sql_exception, it's not that I prefer Exception. I tried using the former a few times and noticed it wasn't working. But can you tell me why using mysqli_sql_exception with mysqli is better than using Exception?

greetings elepil, , Not sure how this question got to be about "Exceptions", since I do not see that in your question? ? ?

You really should have tried to do a prepare() with an execute() in mysqli, from the code examples in the PHP manual, and then ask here in EE, about any problems you had with it. Because the newer prepare - execute operations are SO DIFFERENT, than the old string based Query methods, you need to study some of the PHP manual pages and get a basic understanding of the operations needed, and the reasons they are different for prepare - execute. It is overwhelming true that prepare - execute is much more secure for "SQL injection".

First in your SELECT you use a * for the columns needed, this is a very, very POOR choice, for SQL and, In my opinion, especially for a prepare method; You will do better to list the columns you need, for understanding and trouble-shooting. As you know, in the SQL, you use the ? as a "place holder" for all user input variables (SQL Injections), so there is absolutely NONE , not any SQL string additions from the page user inputs.
after the prepare() method is called, you must tell the MySQL database Engine which Variable REFERENCE from your PHP code will be used as the values passed in the execute( ) method, you must do this with the mysqli statement bind_param( ) method;
Only after the variables have been BOUND by reference, can you call the execute() method;

This next part, is the part that confuses almost Everybody, when first learning - dealing with the row fetch in prepare - execute operations.
You must BIND variables AGAIN, but the second time, for the data pulled from the TABLE columns, you now need to bind your output variables with statement bind_result( ) . . There were several many reasons that this kind of BIND operation was used instead of the OLD way, but it is a very different way to do it, and can be misunderstood from the OLD way.

I have NOT added any ERROR control in the above code, as you should have in development, just to keep this as a easy to understand code progression.

the Main difference in the old query way and the new prepare( ) way, is that in the old way, there was a SINGLE database transaction, usin a STRING, that contained ALL of the elements for the database, the SQL commands, , and the PHP data from variable, that was added to this single, sent string. So string parsing errors in the mysql engine, could lead to SQL injections.

BUT in the new way, there are TWO database sends, the first is with prepare , that sends ONLY the SQL commands (syntax), , NO VARIABLE DATA, as part of the string.
The the second send is with the execute( ), which reads the PHP Variables BY REFERENCE, and sends ONLY the data, and NO sql commands, so no matter what SQL injection parts, are in the variable strings or number, it Can Not affect the SQL commands. Much safer way to do things.

tried using the former [mysqli_sql_exception] a few times and noticed it wasn't working

Not sure what "wasn't working" means. Usually we can get an error message or output from var_dump() to see what PHP is doing with our code. In any case, I would lean in the direction of using mysqli_sql_exception since it appears to be the "front-line" exception for MySQLi hiccups. It extends RuntimeException, which in turn extends Exception. So if you want to use some kind of percolating exception-chained recovery it might be a better choice.

In any case, please try the script I posted, either on your server or on mine and see what the output gives you. I think it's a sensible result, and if you have any questions, please post back.

0

elepilAuthor Commented: 2015-05-07

Slick812, thank you for responding.

I think you missed the point of what I'm trying to do. My goal was to read one row from the database in its entirety (hence the SELECT *), and then have PHP automatically populate my User object with every single column of the row as its properties.

Your example just pulls in three columns of data. I know how to use Prepared Statements in mysqli to do that and use bind_results(). But three columns of data is not what I'm trying to get. What I don't know how to do is how to pull in an ENTIRE row and have PHP instantiate an object (in this case, User) for me, just like I could do in PDO.

0

elepilAuthor Commented: 2015-05-07

Ray,

I tried using with mysqli_sql_exception, and it somehow worked. I'm not sure what I did last time, maybe I didn't put mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_ALL); at the beginning.

But still, I am not seeing any advantages in using mysqli_sql_exception. I checked the PHP manual, it didn't say much at all. It has essentially the same methods and properties as Exception, except the latter has something that mysqli_sql_extension doesn't -- a reference to the previous Exception.

I asked you before and you didn't answer, so I'll ask you again. Can you tell me your exact reasons why you would prefer to use mysqli_sql_exception with mysqli rather than Exception other than "just because"?

I would lean in the direction of using mysqli_sql_exception since it appears to be the "front-line" exception for MySQLi hiccups. It extends RuntimeException, which in turn extends Exception. So if you want to use some kind of percolating exception-chained recovery it might be a better choice.

OK, I did NOT understand your question at all, from your comments there, , , since you say -
"pull in an ENTIRE row and have PHP instantiate an object , , just like I could do in PDO"

The mysqli prepare and execute, is made for more precise, exacting coding, that is does not do many "Automatic" configurations of DB throughput. You can have the * in the SELECT , as you do for a "get every column", , But you still have to tell the mysqli statement , each and every Configured Variable, to use by reference, to get each row data set sent back in the $stmt->fetch() , , by binding them with the bind_result( ) . The use of REFERENCE variables in the PHP while loops for ROW retrieval can be more efficient coding.

But there is the statement get_result() method, and with this, you do NOT need to bind any variables for result pull backs, and will perform in a similar way as the OLD operations by using a while loop with fetch_array( ) or fetch_object( ). So you can then use the -
$result->fetch_object('User', array($username, $password));
with the prepare, although I have never done this,

Just my own thought, and is probably ignorant, , but I use PHP Class definitions and Object to a very large extent in web sites, and I find it better to configure the Class to do specific methods for specific usefulness, such as the operations I implied in the code I showed with -
$pu = $user->setNewUser($id, $access, $icon);
and have the class method do all of the particulars needed for that object to be a good worker, instead of just setting some properties like the fetch_object('User' thing does.

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

When I post on this forum, please don't assume my code to be what I'm using in my application. Like you, you provided a sample devoid of error trapping code. Why? To get your point across as succinctly as possible. I think the same way. So please don't think this is the way I code professionally.

In my actual application, all the above would've been reduced to $userObject = getUser($username, $password). So getUser will be a function somewhere which contains the fetchObject. I do understand your style, as I've seen many people do the same thing. But I try to separate data objects from the business rules. I try to use data objects for one and only one purpose -- to store data related to the class. I guess it is a matter of preference, as long as you can get the job done.