Description: ------------ The attached script runs perfectly when using MDB2 2.3.0. In 2.4.0, all SQL INSERT/UPDATE queries after the commit method is run make no changes to the database whatsoever. I've looked through the code and can't work out what has changed between 2.3.0 and 2.4.0 to cause this behaviour, I'm really stumped. It's completely critical though, my web application no longer functions. What's worse is, if the connection to the database is opened in persistent mode, it can take a minute for the php script to run! There is a block of code commented out... if you uncomment this code, it begins a new transaction and commits this third test query. At this point, all of the previous statements (the second test query and the log queries) appear in the database. Any further log queries do NOT appear in the database. It's quite clear therefore that AUTOCOMMIT has been disabled by the call to the commit method. I've no idea why! There is a link to another version of the test script, the only difference being that it calls inTransaction rather than accessing the in_transaction variable directly... the reason for this is that inTransaction() doesn't work in 2.3.0 so the second file can't be used to show how things break in 2.4.0 but were working in 2.3.0 Test script: --------------- http://dev.ceon.net/web/pear/test_mdb2.phps http://dev.ceon.net/web/pear/test_mdb2_2.phps (uses InTransaction() instead of accessing in_transaction directly).

Hi, Found the problem... was quite easy to find, wish I had just taken a break from the computer instead of writing that test script, it was a pretty obvious one! Anyway... :) In 2.4.0 a new method for determining the server's capabilities was added: "_getServerCapabilities()". This method uses a static variable to save having to parse the capabilities more than once. However, the "connect()" method resets two of the variables which are set up by "_getServerCapabilities()": $this->start_transaction = false; $this->varchar_max_length = 255; This means that a non-persistant connection will result in the disabling AUTOCOMMIT after a commit, even though "beginTransaction" had just started a transaction with a "START TRANSACTION" query. The fix is to remove these two "resetting lines" as the variables are already initialised when an instance of the class is created. Hope you can update this soon so no-one falls into the same trap I did! All the best... Conor

The same two lines are also in the constructor in the mysqli driver

Hi, Just to follow up on the previous comment from Edward... Lorenzo already knows what can be done to fix this bug (Thanks Lorenzo! :). Just for reference, here's the relevant part of the e-mail I sent to him... ----- There are 5 properties set up by this method. However, only four of them are reset at any point outside of this method: $this->supported['sub_selects'] $this->supported['prepared_statements'] $this->start_transaction $this->varchar_max_length The 5th is not reset anywhere else: $this->supported['savepoints'] I don't see any point in having to parse the server capabilities repeatedly just to set these up, especially since each query can cause connect() to be called on a non-persistent connection, so I think your choice of a static variable is a good one. What you need to do though is to remove the lines which reset those four variables in the "connect()" method. I've searched through the MDB2 code and it is the only place where they are reset. So, to summarise, removing those lines in the connect() method of the MDB2 mysql.php Driver (and the equivalent in at least the mysqli driver, possibly others) would solve the problem. --------- Hopefully works calms down for Lorenzo then this should be fixed easily enough. All the best... Conor

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.