[DB-SIG] Oracle+SQLA: Where are my tables?

Michael Bayer mike_mp at zzzcomputing.com
Wed Nov 20 16:08:01 CET 2013


For SQLAlchemy questions, come on over to our list at https://groups.google.com/forum/#!forum/sqlalchemy .

as far as your .reflect() method, your tables might be under a different owner than the user who you are connecting as, and they may or may not appear to be “visible” locally if the system includes synonyms which match their names.   The “schema” argument to MetaData.reflect() would allow this owner name to be specified.

To diagnose the problem, set echo=‘debug’ on create_engine() as it reflects the tables, then look to evaluate the results being returned by the system view queries being emitted by the reflection process.



On Nov 19, 2013, at 8:27 PM, John W. Shipman <john at nmt.edu> wrote:

> I'm using SQLAlchemy and cx_Oracle to explore a legacy Oracle
> database.  When I use Oracle's sqldeveloper application, I can
> see the tables and their contents just fine.
> 
> When I connect to it using SQLAlchemy, I can create the engine
> with no problem, but after I call the .reflect() method on the
> MetaData instance, its .sorted_tables list is empty.  If I
> connect to a Postgres database and do the same thing, the
> .sorted_tables list is as the documentation says it should be.
> 
> Any suggestions on how to find the tables?  A coworker says that
> tables in Oracle are segregated into namespaces.  Is that my
> problem?
> 
> I would greatly appreciate any assistance.
> 
> Best regards,
> John Shipman, Web Developer, National Radio Astronomy Observatories;
> john at nmt.edu, http://www.nmt.edu/~shipman/
> _______________________________________________
> DB-SIG maillist  -  DB-SIG at python.org
> https://mail.python.org/mailman/listinfo/db-sig

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/db-sig/attachments/20131120/c428c342/attachment.sig>


More information about the DB-SIG mailing list