Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 2.5.0b5

Bug #9502 Strong typing query result misbehaves
Submitted: 2006-11-29 19:08 UTC
From: benblay at gmail dot com Assigned: danielc
Status: Closed Package: MDB2 (version 2.3.0)
PHP Version: 5.1.2 OS: Linux 2.6.15-23
Roadmaps: 2.5.0b4    

 [2006-11-29 19:08 UTC] benblay at gmail dot com (Ben)
Description: ------------ When using the second parameter of queryRow() to strong type results, columns not specified behave erratically. That is, some values are not returned at all. If the same method is used without strong typing, the column values are returned as text without a problem. I've tested this in a variety of ways and it seems that the number of fields that are strong typed are applied to the field set represented by * no matter what. Test script: --------------- Example 1: $insInfo = $db->queryRow('SELECT * FROM "thisTable" WHERE "thisTableid" = '.$rec, array('SectionOneInclude' => 'boolean', 'SectionTwoInclude' => 'boolean')); Example 2: $insInfo = $db->queryRow('SELECT "SectionOneInclude", "SectionTwoInclude", * FROM "thisTable" WHERE "thisTableid" = '.$rec, array('SectionOneInclude' => 'boolean', 'SectionTwoInclude' => 'boolean')); Expected result: ---------------- In Example 1, I would expect to get the entire result set as normal, with the two values for $insInfo['SectionOneInclude'] and $insInfo['SectionTwoInclude'] strong typed to boolean. While the latter does occur, the strong typing also applies to the first two columns of the entire result set. In other words, if the columns of the table were thisTableid, Name, Address, Phone, SectionOneInclude, and SectionTwoInclude, the result expected result is: [thisTableid] => 2 [Name] => ABC Widgets [Address] => 123 Main Street [Phone] => 555-666-7777 [SectionOneInclude] => 1 [SectionTwoInclude] => I'd expect the same result for the second example, except that the SectionOneInclude and SectionTwoInclude fields would be returned at the top of the results. Actual result: -------------- [thisTableid] => [Name] => [Address] => 123 Main Street [Phone] => 555-666-7777 [SectionOneInclude] => 1 [SectionTwoInclude] =>


 [2006-12-01 12:30 UTC] quipo (Lorenzo Alberton)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on by the end of next Sunday (CET). If this was a problem with the 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.
 [2011-12-20 01:36 UTC] danielc (Daniel Convissor)
-Assigned To: quipo +Assigned To: danielc
Additional changes were necessary to get this working. See revisions 321234 and 321210. They'll be in the next release (which will either be 2.5.0b4 or 2.5.0RC1). This is related to bug #18203.