NigelRel3

As I started writing C - not a surprise that I use K&R. The reason I was talking about consistency with brace placing is that the PHP-FIG PSR-2 style (http://www.php-fig.org/psr/psr-2/) uses what I see as inconsistent brace placement... public function sampleMethod($a, $b = null) { if ($a === $b) { bar(); } elseif ($a > $b) { $foo->bar($arg1); } else { BazClass::bar($arg2, $arg3); } }

Same here - find a style and just stick to it. IMHO there are issues with all of them, but the main thing is consistency makes it easier to read code. Personally I've always done function someName() { } Which is consistent with other things like if ( someDodgyComparison == true ) { while ( thereIsMoreToDo == true ) { } }

I agree - it could be an indication that something is wrong - but data can be sourced from all sorts of places, sometimes it is a case of just having to deal with it. It's especially the case when the data is from a third party and there may be nothing you can do with the source data, you massage it to fit into what you need. Working with data loads can provide a great insight into what people try and do and your left with the impression that relying on people to do anything correctly and consistently is like trying to juggle water.

Your check if the shirt number already exists is checking that a player_id already exists - nothing to do with the shirt number (or team)! I'm not sure if your database structure is correct though - if a player is just part of one team - then put the team number on the player record . If you want players to be in multiple teams - then put shirt number of the other record. Then create a unique key on team, shirt number.

Have you tried... trim(TRAILING ']' from trim(leading '[' from g.field_value))

If you want to fetch each value separately then SELECT `adequacaos`, count(`adequacaos`) FROM `rel_atividades_avaliacao` group by `adequacaos`; should give you some totals

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.

You would have to identify just the rows that have changed and update them, so it means finding the players that have been changed and using the match id and old player id to update that specific row to have the new player id.

It would help if you can give the source script and the results, just saying something doesn't work is impossible to solve.

You will have to rename one of the fields as having 2 fields called id isn't that helpful. As for how to compare two values passed into a script - it would be better for you to attempt something and post where you are struggling rather than just ask 'how can I achieve that'! This is something fairly trivial and should be quick to work out from almost any example using parameters.

If I were to do as you are trying to do, I would pass the object in rather than have to add another stage of fetching the data from the object to then pass into the table layer. One thing which you should certainly change is that you should use bind variables for your PDO statements! Do not just dump data directly into any SQL statement.

On the subject of how to catch/manage errors (exceptions or any combination) - is there a common way in which a PHP applications can trap, log errors and then present the user with a 'Something went wrong' screen, or is this down to individual implementations? I can see the problem here is that this relies on all of the potential areas for errors being complete prior to building any screen output - or does it? Is this something a framework would have built in (am starting to look into Lavravel). (Sorry for asking so many questions as I'm trying to find out as much as possible from people who actually do these things)

Hmmm... I've changed it to print_r($db->errno); $msg = "SQL failed -".$db->error; And that now gives me 0 as the errorno (even though in the Variable panel I can see a value of 1146 at the point of executing that statement. Once I've stepped over the print_r line, the values are reset. Think I may have found the culprit - the very helpful debugging. If I run the code without debugging, it works as expected, through debugging must be doing as you've said and causing some side effects by getting statuses or something. I use Eclipse and XDebug which although is very useful at times, I must remember that database objects may be affected!

It's early and I'm probably just missing something obvious, but it's confusing me... if (! $stmt = $db->prepare($sql)) { print_r($db); //echo "Error=". $db->error."<br />"; //$msg = "SQL failed -".$db->error; print_r($db); } The above code is intended to trap a failure in a prepare and give me something meaningful out of it. BUT the output (abbreviated) I get from this is... mysqli Object ( ... [connect_errno] => 0 [connect_error] => [errno] => 1146 [error] => Table 'warehouse.BinType1' doesn't exist [error_list] => Array ( ) ... mysqli Object ( ... [connect_errno] => 0 [connect_error] => [errno] => 0 [error] => [error_list] => Array ( ) ... So even simply doing a print_r on the $db object is causing the error to be cleared. Even stepping through on debug shows that when I arrive at the (commented out) echo statement or the second print_r - the values have been cleared. The $db object is from a straight forward new mysqli() and it works for most things I've tried so far. So I thought I'd ask for some enlightenment and in the meanwhile I'll fix the SQL causing the error :-/ Thanks

Firstly - you should be using either mysqli or PDO - mysql_query is outdated and should be your first thing to remove. The main thing about SQL injection is to not directly put the user entered string into a SQL statement, both mysqli and PDO support bind variables. This allow the statement to have a place holder and effectively the value is linked to the statement in such a way as to stop SQL injection attacks.

This is not a way to do it. I'm not sure of exactly what your reasons for doing what you are doing. The problem is that in your statement you are going to try and update every record for a particular matchid to (for example) have a playerid of 1. What you probably want to do is just have a list of player ID's and want to make sure that your set of records match. Update isn't the way to do it. It would probably be better and a lot easier to delete the existing records and insert new records.

You still seem to be referring to a field called 'stack' in your SQL, is this the 'stock' field on the table.

So you only have two values printed from ... printf ("%s(%s)\n",$row["ProductCode"],$row["L1"],$row["L2"],$row["L3"],$row["L4"],$row["L5"],$row["L6"]); the %s indicates that the value of a string should be included (from the parameters), so have you tried adding more %s's to print out all of the values? If in doubt - use something like print_r() which outputs a variable with all of it's components in a readable format.

Firstly - this line $sql = $this->db->prepare("UPDATE items SET stack=:f AND dod=:g AND position=:h WHERE ID=:e"); the syntax is incorrect, if you are updating several values - then you use a comma between items - not 'and'. As Barand was asking - what is the table structure? Can you show the list of columns and what each one is defined as? What you show in your last post show one column and this seems to be different to what your using ('stock' instead of 'stack'). Lastly - BUT most importantly - you don't at any point check that your statements have prepared/executed correctly - you simply assume that everything has worked OK and carry on. You should assume nothing - check at each stage if what you've just done on the database has worked! At some point this is going to come back and produce more problems.

It looks as thought the user that is running the php process (not sure who this is on Windows) doesn't have read access to these files. Are these files under your webserver root directory (where your PHP scripts are)? (You can rung phpinfo() to check this) Are the permissions similar to the .php files your running?

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.

Interesting approach - something which I've not seen before, I can see where some systems this is vital - but others is it a bit of overkill? Out of interest - do you have any idea at what point performance becomes an issue? Just that with SQL usually being the slowest part of most systems, I can imagine that over time or with high volumes of transactions, this may become an issue.

As already mentioned - using multiple statements in one string will not work. You could rewrite your query though to be something like UPDATE stock s1, stock s2 set s1.qty = s1.qty-1, s2.qty = s2.qty +1 where s1.id= 1 and s2.id= 1 you'll have to change the names as appropriate - and BIND the variables for the ID's.

Even if OP was to change his code to write an XML/JSON/.ini file format instead, I assume they will still have the same problem which they raised - which was they can't write the file due to permissions problems.

Have you tried to search for 'php string csv'? Probably a good starting point.