Skip navigation links
MySQL 3.23, 4.0, 4.1 Reference Manual :: B MySQL Change History :: B.3 Changes in Release 3.23.x :: B.3.24 Changes in Release 3.23.36 (27 March 2001)
B.3.25 Changes in Release 3.23.35 (15 March 2001) »
Section Navigation      [Toggle]

B.3.24. Changes in Release 3.23.36 (27 March 2001)

End of Product Lifecycle. Active development and support for MySQL Database Server versions 3.23, 4.0, and 4.1 has ended. For details, see http://www.mysql.com/about/legal/lifecycle/#calendar. Please consider upgrading to a recent version. Further updates to the content of this manual will be minimal. All formats of this manual will continue to be available until 31 Dec 2010.

  • Fixed a bug that allowed use of database names containing a “.” character. This fixes a serious security issue when mysqld is run as root. (CVE-2001-0407)

  • Fixed bug when thread creation failed (could happen when doing a lot of connections in a short time).

  • Fixed some problems with FLUSH TABLES and TEMPORARY tables. (Problem with freeing the key cache and error Can't reopen table....)

  • Fixed a problem in InnoDB with other character sets than latin1 and another problem when using many columns.

  • Fixed bug that caused a core dump when using a very complex query involving DISTINCT and summary functions.

  • Added the SET TRANSACTION ISOLATION LEVEL statement.

  • Added FOR UPDATE for SELECT statements.

  • Fixed a bug where the number of affected rows was not returned when MySQL was compiled without transaction support.

  • Fixed a bug in UPDATE where keys were not always used to find the rows to be updated.

  • Fixed a bug in CONCAT_WS() where it returned incorrect results.

  • Changed CREATE ... SELECT and INSERT ... SELECT to not allow concurrent inserts as this could make the binary log hard to repeat. (Concurrent inserts are enabled if you are not using the binary or update log.)

  • Changed some macros to be able to use fast mutex with glibc 2.2.


User Comments

Posted by Mike Wexler on June 17 2002 3:39pm[Delete] [Edit]

The documentation on $sth->{rows} should talk
about the difference between rows matched and
rows changed.

For example

UPDATE foo SET bar=1 WHERE uniqueKey=1

Could set rows to 0 or 1 even if there was
exactly one record with uniqueKey=1 if the field
bar was already 1 $sth->{rows} would be zero
otherwise $sth->{rows} would be 1. Also a pointer
to how to get the other piece of information
(rows matched) would be nice.

Posted by Begrudged Biker Mouse on June 17 2002 3:39pm[Delete] [Edit]

Some of the field names listed there seem to be incorrectly cased. For example, using the current DBI::mysql, after a $sth=$dbh->prepare("LISTFIELDS users"); $sth->execute();, $sth->{TYPE} is set (as an ARRAYREF of types) but not $sth->{type}. Readers should probably consult the DBI docs if some fields turn up undef when typed in the cas mentioned here.

Add your own comment.