The message - Deprecated: mysql_connect() should give you a hint, if you read up on this you will see that you should follow the suggestion that it gives and change the way you interact with the database.
So - yes - this is causing the database to not be updated.
if you have any type of account (bank, credit, loan, itunes, cell phone data plan, in game purchases, ...) that keeps track of an amount (quantity or money) or have ever done any in person or on-line shopping, you have seen this being used. it's not overkill, it's a necessity that's used everywhere in real situations. it gives you a record/audit trail of each transaction, so that you know all the who, what, when, where, and why information about each transaction. this lets you detect and correct errors, produce reports,... this method also has the advantage of correctly working with multiple concurrent users, since the changes made by each user will be recorded separately (at least the OP removed a race condition, by eliminating a separate SELECT query to get the 'current' starting amount.)
without doing this, by just maintaining the amount in a field, there's no record of any duplicate data submissions, incorrectly entered values (transposed digits, hitting the wrong key), programming errors, fraud/cheating, ... the first sign of a problem is when someone tries to use an amount, that the system says exists, but it doesn't.
if the OP is really doing an inventory system, that's more than just a classroom assignment or part of a beginner's attempt at making a game, the current method will eventually get out of sync with the actual products and you won't know which of the possible reasons why because there's no record being kept of what values have affected the total.
I can understand the financial reasons for doing this (and I did say that in some systems it may be overkill), but I've worked with systems where you have tens of thousands of products, some with histories going back for several years. (In this system) There is an inherent assumption that there will be mistakes in values and as stock goes missing/gets damaged it gets recorded and the overall stock figures are manually checked on a regular basis during stock takes when the correct figures are recorded.
(Just wondering of the overhead it would cause if for various reports to use the audit trail as opposed to the main stock records. Actually wonder if the full audit trail is still available - hmmm.)
I guess that any design has to weigh the accuracy and 'currentness' of any data against the cost of maintaining it and the chance that the figure isn't correct anyway. It's probably easier when dealing with transactions that only have a logical existence rather than physical objects which have a lot of external factors in play.
Thanks for that anyway - makes me think about the design considerations for future systems.