Fri, 10 Apr 2026 06:34:47 +0000 https://bugs.horde.org/ticket/7542 MDB2 error on changing share permissions with SQL Driver Horde 3.3 with (sql shares driver) MDB2 2.4.1 MDB2_Driver_pgsql 1.4.1 MDB2_Driver_querysim 0.6.0 MDB2_Schema 0.8.2 PostgreSQL 8.1.11 Changing permissions for shares ersults in an MDB2 error prepared statement "mdb2_statement_pgsql_0e0c6cd9ec2d2223511d9bc21134714a" does not exist The executeMultiple() tries to execute the prepared statement for each user, which has permissions on the share. The databese log shows that the execute inserts the permissions for the first user (normaly the owner of the share). Than the databaseconnection is reset. After a reconnect the next execute fails as the prepared statement does not exist anymore. The reset of the databaseconnection is caused by the function _selectDB in lib/Horde/Share/sql.php The function was introduced with the patch http://cvs.horde.org/diff.php/framework/Share/Share/sql.php?r1=1.47&r2=1.48&ty=u which was done to solve the BUG http://bugs.horde.org/ticket/6997 Thu, 23 Oct 2008 07:44:12 +0000 https://bugs.horde.org/ticket/7542#t49895 Even though this patch was a workaround only, it works fine for MySQL. Someone who has better knowledge of PostgreSQL's connection handling and the details of MDB2 has take a look at it. My first guess is, that the pgsql driver handles unsetting of connected_database_name differently than the mysql driver. Fri, 24 Oct 2008 10:20:37 +0000 https://bugs.horde.org/ticket/7542#t49946 I updated bug #6997 with the irc discussion that led to the current solution. Fri, 24 Oct 2008 10:29:00 +0000 https://bugs.horde.org/ticket/7542#t49949 Changes have been made in CVS for this ticket: http://cvs.horde.org/diff.php/framework/Share/Share/sql.php?r1=1.58&r2=1.59&ty=u http://cvs.horde.org/diff.php/horde/docs/CHANGES?r1=1.1176&r2=1.1177&ty=u Fri, 07 Nov 2008 04:32:06 +0000 https://bugs.horde.org/ticket/7542#t50434 The difference isn't in connected_database_name, it's that the postgres driver uses real prepared statements while the mysql driver emulates them. I think the fix is to just not use executeMultiple. Done for 3.3.1. Fri, 07 Nov 2008 04:32:09 +0000 https://bugs.horde.org/ticket/7542#t50435 This seems inefficent to me as the connection is resetted and the prepare-statement is executed for every user and group that has permissions on a share. I think it would be better to reset the databaseconnection only if there is a need to do so. We don't use Groups, but grep -R -F executeMultiple * showed that there is also lib/Horde/Group/sql.php which uses executeMultiple. Is there the same problem? Fri, 07 Nov 2008 08:06:17 +0000 https://bugs.horde.org/ticket/7542#t50441 This is only on updates; of course it's not ideal, but if there are enough updates going on for load to be an issue, you'll run into bottlenecks in other places far sooner. It's not an issue for groups; the debug handler isn't used there (so hopefully isn't necessary). Fri, 07 Nov 2008 17:02:37 +0000 https://bugs.horde.org/ticket/7542#t50450 The changes done for http://bugs.horde.org/ticket/?id=7825 obsolate the changes for this Bug so executeMultiple can be used again. Tue, 27 Jan 2009 15:45:46 +0000 https://bugs.horde.org/ticket/7542#t51992 executeMultiple is just doing the same thing we do, maybe *slightly* more efficiently depending on the actual db handling of prepared statements, etc. Anyways this code will be ported to Horde_Db for horde 4, so I don't see a need to mess with it if it's working. Thu, 29 Jan 2009 15:53:44 +0000 https://bugs.horde.org/ticket/7542#t52090