Description: ------------ The way the query to fetch user indexes from the database schema is written will often return the wrong result set. I don't think this query is doing what the programmer intended, because the logic of the query works out to be: table_name='ARTICLES' OR (table_name='ARTICLES' AND generated='N') instead of (table_name='ARTICLES' OR table_name='ARTICLES') AND generated='N' This query (as it appears in the module) returns three rows from my database, all of which are Oracle-generated indexes. When I run the query with the proper parentheses the query returns the empty set, since all of the indexes in my table are generated. This seems to be related to bug #8531, in which is was determined that Oracle-generated indexes should not be used in this context. Test script: --------------- MDB2/Driver/Manager/oci8.php, line 744: $table = $db->quote($table, 'text'); $query = 'SELECT index_name name FROM user_indexes'; $query.= ' WHERE table_name='.$table.' OR table_name='.strtoupper($table); $query.= ' AND generated=' .$db->quote('N', 'text'); This ends up generating a query like: SELECT index_name name FROM user_indexes WHERE table_name='ARTICLES' or table_name='ARTICLES' AND generated='N' Expected result: ---------------- no rows selected Actual result: -------------- NAME -------------------------------------------------------------------------------- SYS_IL0000013728C00011$$ SYS_IL0000013728C00015$$ SYS_C004037

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.