can you please provide a very simple test case for me?  all local attempts here have not yielded the same results as you are seeing.

a sample schema, and script to reproduce this would be very nice.  but please make sure it's all in the simplest form...

no feedback, considered closed.  if untrue, please reopen the bug.

I am having the same or very similar problem:

(There's a bunch more code involved, of course, so I'm just including relevant examples, below.)

<-------- START EXAMPLE ------->
<...appropriate persistent db access info...>
<...data-to-variable assignments...>

mysql_db_query("dbX","update tableX set col1='$data1' where ID='$id'");

<...error-reporting code...>

echo mysql_affected_rows();

<------ END EXAMPLE ------>

Result: no affected rows, no errors, and no update

I tried adding a SELECT statement immediately following the UPDATE statement, per this bug report's suggestion:

Result: 1 affected row, no errors, and no update

So PHP thought 1 row had been updated...but it had not been.

This is a piece of script that we have been using successfully for about 4 months, but it started to malfunction about 3 weeks ago.

INSERT, and DELETE statements work fine.

Version Info/Configuration:
 FreeBSD 4.4 Release i386
 PHP v. 4.1.2 (same problem with 4.0.6, by the way...)
 Apache/1.3.12 OpenSSL/0.9.6a
 MySQL v. 3.23.44

Thanks.

Sorry...my PHP Configuration is:

'./configure' '--enable-inline-optimization' '--with-apxs=/usr/local/apache/1.3.12/bin/apxs' '--with-config-file-path=/usr/local/lib' '--disable-debug' '--enable-memory-limit' '--with-gettext' '--without-pear' '--with-regex=system' '--enable-mbstring' '--enable-mbstr-enc-trans' '--with-iconv=/usr/local' '--with-gdbm=/usr/local' '--with-dbm=/usr/local' '--enable-sockets' '--enable-versioning' '--enable-ftp' '--with-imap' '--with-mcrypt=/usr/local' '--with-mhash=/usr/local' '--with-mysql=/usr/local/mysql' '--with-zlib' '--with-zlib-dir=/usr'

please try turning on autocommit or doing a commit command before your script ends.  Once again I am still unable to reproduce this locally... still considered closed.

MySQL has autocommit enabled by default. We are using ISAM-type tables, which do not support transactions, so every request MUST be written immediately to the table. (There is no memory-space in which to store the transaction.)

UPDATE (and now INSERT and DELETE) statements are now functional when I use a SELECT statement to read the entire table content immediately after the UPDATE, INSERT, or DELETE statement, as per the original bug report notes.

When I first wrote my comment, this was not working as described...but now it seems to be, without me making any changes! Also, INSERT and DELETE used to work, but have since begun to require the same "fix".

This "feels" like a software degeneration bug to me. The affected scripts were working just fine up until about three weeks ago, and then...no UPDATE...and then last week...no INSERT or DELETE.

It's hard to believe from looking at this note that I didn't make any changes to the scripts that would affect them, but it's true: I am trying to fix the problem on a separate, initially-duplicate set of scripts, so as not to disrupt the live site. The live site is the one that is coming-and-going, and my test-set is the one I'm experimenting with. The original scripts (that worked) have been up and running for over six months without trouble.

The Apache module we're running is:
  mod_php4-4.1.2-module-mysql-mcrypt-ftp-imap.so

For additional testing, I reverted to:
  mod_php4-4.0.6-module-mysql-mcrypt-ftp-imap.so
with the same results.

Executing the UPDATE, INSERT, or DELETE commands via telnet, on the command line, is always successful. The problem appears when I try to do it with PHP via a form (both GET and POST methods; string-length doesn't matter).

(Currently, we are using the command line method, and not the PHP form, just to get the work done.)

Thanks again. I hope you can replicate this in your labs. It's possible that the combination of softwares are munging improperly, or...?? Geez...thanks for your efforts.

Is there any information I could send to help you duplicate the environment? It looks like the original bug-noter is using a Windows system, where we are on FreeBSD.