As mentioned in ticket, the original fix seems faulty because it 
assumes that we are using DB caching.  At the very least, that fix 
completely breaks installations so it is necessarily reverted until 
properly fixed.

Changes have been made in Git for this ticket:

Revert "Fix creating cache objects for Horde_Db."
This reverts commit 6c7b1ce4d9b529822899af05df6b5a00ea414b8d.

Bug #10460

Fixes fatal error that completely prevents viewing of any page.

I am using PostgreSQL as DB driver, files as cache driver. The code
seems to assume that the cache driver will ALWAYS be a SQL DB.  This is
obviously incorrect.

  2 files changed, 1 insertions(+), 7 deletions(-)
http://git.horde.org/horde-git/-/commit/592009d780a35b7ad66781489e726f94fcdd4234

This was a bug in Horde_Core.

Changes have been made in Git for this ticket:

Fix creating cache objects for Horde_Db.
We cannot simply pass the current Horde_Db object into the Horde_Cache 
instance
that we pass back to that object, because we might be creating a Horde_Db
object for a completely different SQL configuration than required for
Horde_Cache.
Create a new Horde_Db object with the separate cache configuration 
instead, but
set this object's 'cache' property to avoid an infinite loop.

Bug: 10460

  2 files changed, 7 insertions(+), 1 deletions(-)
http://git.horde.org/horde-git/-/commit/6c7b1ce4d9b529822899af05df6b5a00ea414b8d

Nevermind, I forgot to change the Cache backend.

I cannot reproduce. How does your backends(.local).php look like?

When using an external mysql addressbook (different database than the 
HORDE DB), Turba tries to write something into the horde_cache table 
using the external mysql ressource instead of the HORDE DB. This 
happens in browse.php.