Well, this is definitely not a horde bug then. We are passing the 
correct constant to the correct PDO library call, and getting back the 
wrong data structure.  You can try investigating this further with 
your distribution's PHP maintainer, or try compiling PHP from source.

PHP VERSION: 5.2.3-1~edh.0
PDO::FETCH_KEY_PAIR: 12

I had issues with updating php5 with debian etch. maybe that's the reason?

Also, what does echo PHP_VERSION output?

Alright, well, since those results are coming directly from PDO, that 
leaves two possibilities: either your PHP build is broken, or the PHP 
documentation is incorrect.

Can you see what the following outputs on your system?
echo constant('PDO::FETCH_KEY_PAIR');

I have PHP Version: 5.2.3-1~edh.0. So this coding is not working for me.

Try now?

Changes have been made in Git for this ticket:

PDO::FETCH_KEY_PAIR is only available since PHP 5.2.3
Bug: 9223

http://git.horde.org/diff.php/framework/Db/lib/Horde/Db/Adapter/Pdo/Base.php?rt=horde-git&r1=c104a5b3f580a516f34d2c1efe7241a167e280f4&r2=f6c4867ad140073c32b030c0510c31b0aa7d688f

Ok. I think I know what' s wrong.  What version of PHP are you running?

array(2) { [0]=>  array(1) { [1]=>  string(8) "calendar" } [1]=>   
array(1) { [2]=>  string(5) "event" } }

what is the result if you dump fetchall results from line 145 of 
Adapter/Pdo/Base.php?

No, it looks fine. That's the adapter that I'm using with no issues.   
Horde_Db_Adapter_Pdo_Mysql extends Horde_Db_Adapter_Pdo_Base, and the 
implementation in *_Pdo_Base looks fine.

Are you sure you are 100% up to date with git and have no local modifications?

Horde_Core_Factory_Db

I guess I found the issue. The implementation of the pdo_mysql adapter 
is incomplete. I changed the coding to switch to normal mysql adapter. 
Now kronolith and perms are working fine. I assume the mysql-specific 
coding for selectAll is missing in pdo_mysql. Can you confirm?

In old versions there was a factory method in Adapter.php for 
implementing the Horde_Db_ class. Where is this logic done now?

Passing on to Chuck... I can't reproduce and I'm not as intimate with 
Horde_Db code.

I just tested PDO with this snippet. It was working fine.
$dbh = new PDO('mysql:host=localhost;dbname=test','mydbuser','mydbpassword');

In test.php I can see the pdo_mysql extension is activated. I am just 
wondering because the function list is empty. Is this maybe an issue?

...sure, but do you have the mysql pod module as well? This is 
separate from PDO itself, and different then the native mysql support.

With the Horde System Test I get the following:

PHP Module Capabilities
MySQL Support: Yes
PDO: Yes

Do you have pdo and pdo_mysql enabled in PHP?

It seems it's not only a kronolith/content issue. I have a similiar 
issue with perms. It seems I am only using base and not the mysql 
specific db adapter. any ideas?

db->selectAssoc is calling db->selectAll. If I compare base and mysql 
implementation, selectAll is coded differently. Content is using only 
base at the moment. I guess thats the issue.

Here is the dump I get. I am using mysql
array(2) { [0]=>  array(1) { [1]=>  string(8) "calendar" } [1]=>   
array(1) { [2]=>  string(5) "event" } }

Sorry to belabor the point, but this is the output of:

             var_dump($this->_db->selectAssoc('SELECT type_id, 
type_name FROM ' . $this->_t('types') . ' WHERE type_name IN 
('.implode(',', array_map(array($this->_db, 'quote'), 
array_keys($typeName))).')'));

?

When I dump that, I (correctly) get:


array(2) { [1]=>  string(8) "calendar" [2]=>  string(5) "event" }

Here's the export of my table:

CREATE TABLE `rampage_types` (
   `type_id` int(10) unsigned NOT NULL auto_increment,
   `type_name` varchar(255) NOT NULL,
   PRIMARY KEY  (`type_id`),
   UNIQUE KEY `rampage_objects_type_name` (`type_name`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=6 ;

INSERT INTO `rampage_types` (`type_id`, `type_name`) VALUES
(1, 'calendar'),
(2, 'event');

The result of the db-statement is:
Array ( [0] => Array ( [1] => calendar ) [1] => Array ( [2] => event ) )
-> $id=0; $type=Array ( [1] => calendar )
-> $id=1; $ype=Array ( [2] => event )

You are getting these values inside the foreach loop that does the 
db->selectAssoc() call (line 70 or so)?  That looks badly broken.   
What does your table look like?

Exactly there's the problem in the loop. Here is my debugging:
1. loop:
$key: 0
$type: Array ( [calendar] => 1 )
2. loop:
$key: 1
$type: Array ( [event] => 2 )

If I understand everything right, it should be:
1. loop:
$key: 1
$type: calendar
2. loop:
$key: 2
$type: event

By the way, can you *please* use a real email address when reporting 
bugs, devs get multiple bounce notices each time one of your tickets 
is updated.

No, it should be an array, that's why it's in a foreach loop.  That's 
what selectAssoc() is expected to return. type_id should be the key, 
and type_name is the value.  So.... in the loop, $id is the type_id 
and $type is type_name.

The db statement is returning an array. I assume this should only be a string?

Array ( [0] => calendar )
Warning: Illegal offset type in /horde/content/lib/Types/Manager.php 
on line 71
Warning: Illegal offset type in unset in 
/horde/content/lib/Types/Manager.php on line 72

as I stated earlier, I am not seeing any issues.

The coding seems to be even more complex. At the moment I can hardly 
believe this part was ever working. Can you confirm?

Yes, you're right. The problem is $typeName consists of name/id, but 
the sql statement is returning id/name. So the unset is not working. I 
am using Mysql. Any idea?

That code is incorrect and will likely corrupt your content data.

You can see what the query on line 69 returns from your DB, and 
compare it with what you think it should return.

The issue comes from the Content_Types_Manager class, Function 
ensureTypes. If I change the coding from "if (is_int($type)" to "if 
(is_int($typeIndex))" everything works fine.

My database looks like this:
type_id         type_name
1         calendar
2         event

No luck, the error is coming again. I will try to investigate

it seems there was an issue with the db_migrate script. after 
migrating down and up again. everything works fine. thx

I can't duplicate this. What RDBMS are you using? Have you changed 
anything related to the database? Can you provide steps to reproduce?

A fatal error has occurred
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 
'calendar' for key 2