On Aug 7, 2012, at 11:39 AM, Michael Bayer wrote: > > On Aug 7, 2012, at 7:57 AM, Peder Chr wrote: > >> But this does not work in SQL Alchemy - the trivial attempt of specifying >> the 'schema' parameter of the 'Table' constructor as >> 'databasename.schemaname' instead of just 'schemaname', using a DSN that >> does not specify a database name, results in a NoSuchTableError. > > this is the correct way to do it. > > NoSuchTableError is raised in specifically the case where you're trying to > reflect an existing table (autoload=True), and its possible that when two > tables have a foreign key dependency, reflection isn't aware that it needs to > add this additional prefix to the FK definition. > > The workaround here would be to not rely upon reflection for this use case, > and to declare Table metadata explicitly.
yeah, reflection needs special steps if the schema has a "database name" in it. In 0.8 I've just committed r969156caad35 which adds this feature to the MSSQL dialect - if the schema is detected as "<dbname>.<owner>", each reflection method will emit a "USE <dbname>" before running the operation, and then a second "USE <prev_db>" to switch it back. for now hopefully you can work with explicit Table sections. The new feature is backportable to 0.7 though I'd rather just keep it for 0.8. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
