mysql UPDATE issues

[darkpunkcalob]

I am normally a "hack at it till it starts working and never ask anyone for help" kind of guy, but i just dont get this

What is this code would cause there to be no error report, and yet for the update to not take effect?
(Assume the connection was already made and the POST values are correct, I am only posting the segment I am having issues with)

$date = $_POST['date'];
$title = $_POST['title'];
$author = $_POST['author'];
$content = $_POST['content'];
$link = $_POST['content'];
$qupdate = "UPDATE $table 
            SET title = '$title', author = '$author', content = '$content', attachments = '$link' 
            WHERE date = '$date' AND title = '$title'";
mysql_query($qupdate) or die("Failed: " . mysql_error());
echo "[" . $title . "] updated for [" . $table . "]!"; 

[misson]

Besides the injection vulnerability (even though it's an excerpt, you should really be using PDO and prepared statements), if there are no rows with the given date and title (I notice you both select against and update the title), the update will fail. If you're using transactions and don't commit them, the update won't take effect.

Print the statement and execute it directly. You can also see if mysql_info or turns up anything interesting, such as if the number of matched rows is 0 (which you could also do with PDOStatement::rowCount). A SHOW WARNINGS might also turn up something interesting.

[darkpunkcalob]

You are rather condescending.

I am more than aware of the security risks and exploitations, and am simply looks for reasons on why my tables are not updating.

Thank you, however, for the information you did provide about mysql_info

[mandy0]

If i am not wrong you haven't initialized $table .. Please check it out .. I am half asleep I might have made mistake .. but it seemed so for me.

[darkpunkcalob]

This issue has been solved, thank you.

[mandy0]

Alrite bro.. No problem . I just seen this so posted never mind

[misson]

You are rather condescending.

I write in a no-nonsense style. Tone doesn't come through very well in online communication. I'm sorry if you felt condescended to, that wasn't my intention.

It's better I tell others something that they already know than assume they do. Most of the people who posted the above code on this board wouldn't have known about SQL injection (or information disclosure or the problems with or die).

Good to hear you resolved the problem. Out of curiosity (and to help any others that have the same problem), what was the root cause and solution?

[darkpunkcalob]

A typo, nothing more. I had formatted the date wrong, and so it did not find the entrée I specified.

As for the issues with die and mysql_error, these are only problems if they are used on public web space, and not pages designed for developer use, where having as much feed back as to the source of the issue is an advantage.

I would have assumed that after one had developed a page designed for public view, they would remove all error reporting code anyway.

As for your style of communication, it was far from no-nonsense. It is highly opinionated, and the links give the feeling of a teachers scolding than a helpful resource. By providing links, you are insinuating that the one you are talking to is incapable of using google. The fact that you decided to mention the security of specific code, especially in the stead of information pertaining to the content of the initial post, also implies that you consider yourself more educated on the subject than the next guy, not even knowing who the next guy may be.

I hope you can see how this would make one feel looked down upon.

[misson]

As for the issues with die and mysql_error, these are only problems if they are used on public web space, and not pages designed for developer use, where having as much feed back as to the source of the issue is an advantage.

I would have assumed that after one had developed a page designed for public view, they would remove all error reporting code anyway.

Sometimes scaffolding is accidentally left in (it's easier than you might think when dealing with a large code base and multiple programmers). Even when it isn't, some form of error handling has to be put in place. Having to replace one set with another is wasted effort.

I personally prefer to log extended information privately or use an interactive debugger. That way, I can publish code without having to edit it. Also, if I forget to disable the error reporting code, it doesn't compromise anything. One off scripts are a different matter, of course.

As for your style of communication, it was far from no-nonsense. It is highly opinionated, and the links give the feeling of a teachers scolding than a helpful resource.

What's opinionated about how SQL injection works, and that it should be prevented? I think you're attributing an opinion to me that I don't possess.

By providing links, you are insinuating that the one you are talking to is incapable of using google.

You'd be surprised at how often novices don't search for more information.

The links are there to expand on whatever point I'm mentioning, to provide both explanation and support for my statements.

The fact that you decided to mention the security of specific code, especially in the stead of information pertaining to the content of the initial post, also implies that you consider yourself more educated on the subject than the next guy, not even knowing who the next guy may be.

There isn't a single next guy, there is a group. Some will know more, some will know less. The links are for those that know less. Those that know more can ignore them. Personally, I always at least skim linked documents, in case they have information new to me.

Providing links and bringing up other potential problems with code are considered the right thing to do.

I hope you can see how this would make one feel looked down upon.

I can see how someone might interpret it that way. However, that has more to do with a mismatch in communication styles.


Looking back at my first post, it seems the part you might be taking the most umbrage at is "even though it's an excerpt, you should really be using PDO and prepared statements." An explanation might clear things up a little. By dealing with injection in code samples, it demonstrates you are aware of the issue. Alternatively, mentioning that the actual code handles SQL injection also shows awareness (though demonstrating it in code would be better, as a few people know about SQL injection but don't prevent it properly). Otherwise, I have know way of knowing what you know.