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

Request #11297 Add schema-owner support to the Reverse module
Submitted: 2007-06-12 18:48 UTC
From: quipo Assigned: quipo
Status: Closed Package: MDB2 (version 2.4.1)
PHP Version: 5.2.2 OS:
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 39 - 18 = ?

 
 [2007-06-12 18:48 UTC] quipo (Lorenzo Alberton)
Description: ------------ Request from Hugh Dixon: -- I'm hitting some new issues with MDB2 reverse engineering on Oracle .. - basically because I'm using it in an "enterprise" scenario, I guess, where the tables and access are managed by the DBAs. So in this particular case, the tables where my apps data are held are owned by a different user from the user the app is allowed to access them from (ie. in their schema not the "access" schema). Totally breaks the tableInfo() and descendent functions because they look in user_tab_columns.. Am changing it to accept a flag for "owner (schema)" which can be defaulted to the username used in the DSN to connect I guess. Any thoughts, though, on "adding" the schema/owner concept into the lookups (queries should be ok, as one can always use the "dotted" notation (schema.tablename.column))?

Comments

 [2007-06-12 19:08 UTC] quipo (Lorenzo Alberton)
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.