1

Is this just an issue when there's a problem connecting to the database? (I do check to see if the database connection was successful). Assuming that I do enough checks to ensure that my queries are always valid, is it ever okay to skip the following check:

if($stmt = $db->prepare($query)) { //more code }

and instead just do:

$stmt = $db->prepare($query); //more code

I'm thinking that transactions might make this okay, but my database tables doesn't support transactions (I'm using MyISAM because I'm doing a lot more db reading than writing).

Improve this question
3
  • Regardless of read/write, you should almost never use MyISAM. Foreign keys and transactions are required if you want to be sure about your data. Commented Dec 4, 2010 at 5:21
  • When do you think it would be appropriate to use MyISAM? Any other time than than when you need Fulltext search support? Commented Dec 4, 2010 at 5:43
  • InnoDB locks rows, whereas MyISAM locks whole tables. MyISAM is the default database type for GoDaddy. MyISAM is perfectly fine to use for toy problems where there is only one or a small handful of people using the system, and you don't ever expect heavy simultaneous usage. Commented Jun 21, 2012 at 22:31

1 Answer 1

Reset to default
-1

Tandu provides a severely misleading notion here, which you've unfortunately accepted as an answer.

Regardless of what database abstraction layer you're using (you're using mysqli), it is actually reliant on whether or not the prepared query is emulated, or if it's natively run at the database level. The prepared query can, and should fail, if the underlying database engine fails to "prepare" it.

It has nothing to do with whether or not your database connection was successful.

You absolutely should check the return value of the prepare() call. If you have a programming bug, it will fail. If you have another level of application problem, it will fail. Etc. That's the entire point of the return value.

If you assume it's always good, you're risking a failed query, which would result in loss of data - potentially more.

To be explicitly clear, it's important to check the result any time the query may have failed. Which you don't know... hence always.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Ah, I see what you mean. Thank you for the response. I've chosen your answer as the correct one. Would you agree that in this case, if I create a wrapper class to handle DB connections, if I make a modified prepare() function (which handles failed prepares) accordingly, that would be an acceptable way to go?
Depending on the situation, that is probably an acceptable way of handling it. Be careful though, because if you're using the results of a previous query that failed to execute, you might get orphaned data.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.