Jump to content


NigelRel3

Member Since 07 Mar 2017
Offline Last Active Nov 02 2017 09:21 PM

#1545833 Why my basic insertion won't work?

Posted by NigelRel3 on 24 April 2017 - 03:10 PM

You are trying to insert into 3 values for your insert statement and bind only 1.




#1545497 Warning: mysqli_error() expects exactly 1 parameter, 0

Posted by NigelRel3 on 15 April 2017 - 10:13 AM

The error is very clear - mysqli_error expects a parameter - usually...

mysqli_error($connection)



#1544350 Fatal Error - Help/Guidance to correct

Posted by NigelRel3 on 18 March 2017 - 05:18 PM

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.




#1544107 Update 2 query in sql using php

Posted by NigelRel3 on 11 March 2017 - 01:36 PM

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.