ID: 10155
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: ODBC related
Operating System: Windows NT 4.0 build 1381
PHP Version: 4.0.4pl1
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2002-04-05 18:17:51] [EMAIL PROTECTED]
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.
------------------------------------------------------------------------
[2002-04-04 19:07:57] [EMAIL PROTECTED]
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'
------------------------------------------------------------------------
[2002-04-04 18:46:26] [EMAIL PROTECTED]
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.
------------------------------------------------------------------------
[2001-05-07 10:39:41] [EMAIL PROTECTED]
no feedback, considered closed. if untrue, please reopen the bug.
------------------------------------------------------------------------
[2001-04-16 23:14:21] [EMAIL PROTECTED]
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...
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/10155
--
Edit this bug report at http://bugs.php.net/?id=10155&edit=1
