!Editing Entries In Chapter 12

[Adrian56]

Hi 

New to PHP but have got to the end of chapter 12 and all is great -almost.

 

I was further playing after successfully creating/checking  'edit_entry.php' (script 12.9) and this time hit the 'submit' button before any change had been made to an entry.

This triggered the error 'Could not update entry because: ...'

                i.e. mysql_affected_rows($dbc) = 0

 

Intrigued I played some more

 

Any editing resulting in change successfully runs.

No editing returns the error.

Any editing returning to the original text returns the error.

 

 

I'm having difficulty understanding when/how the script 12.9 has a memory to recognising change /non-change. I thought it was just retrieving & returning values/variables/values to from the db/form/db.

 

Please can you point my thoughts in the correct direction for understanding!

 

 

To Administrator:

Your e-mail filter did not recognise my initial (valid) e-mail address

[margaux]

I dont have this book so I'm guessing at what you're trying to do.

 

By submitting the form without making any changes, the script is probably using the previous values that had been entered. The error is thrown because an update expects change and will return false if you try to do an update without actually changing any values. While in principle no error is made, technically there is an error.

 

After the form has passed validation you might want to clear the $_POST array to prevent exactly this situation, which can be confusing to the user.

[Adrian56]

Margaux

 

Thank you. I went away and looked at a MySQL manual and found this:

 

"If you set a column to the value it currently has, MySQL notices this and does not update it"

(http://dev.mysql.com/doc/refman/5.5/en/update.html)

 

"An integer greater than zero indicates the number of rows affected or retrieved. Zero indicates that no records were updated for an UPDATE statement, no rows matched the WHERE clause in the query or that no query has yet been executed. -1 indicates that the query returned an error or that, for a SELECT query, mysql_affected_rows() was called prior to calling mysql_store_result()."

(http://dev.mysql.com/doc/refman/5.5/en/mysql-affected-rows.html)

 

The mysql_affected_rows($dbc)= 1 is used in the script to report on the query. In the "error" conditions I was describing above, mysql_affected_rows($dbc) = 0

 

The problem is not in the query but the condition set to generate the error message and resetting 'mysql_affected_rows($dbc)>= 0' allows the script to cope with the situation I generated whilst catching any genuine errors.

 

If the above is sound reasoning, I think I've got it. Onwards to chapter 13 - the last chapter!!

 

Once again, thank you.