> there's just a few odd places, and I wonder if "drop table" is one of > them, resulting in the original cause of this thread.
I don't think that DROP is a special case. Look upthread. The incorrect DROP happened in the same wrong schema as the incorrect CREATE. The problem is that the check-table correctly looked in the *right* schema, and so didn't find the table. If the default schema hadn't been monkeyed with along the way, the behavior would be correct. > I think MSSQL's set_default_schema is a bad idea from the start. People > expect it to work as a shortcut for specifying a schema on every table, > and it doesn't work like that. I think we should remove it for now. I agree, it's been a fiddly pain in the neck since inception. Unless someone yells pretty soon, consider it gone. One thing left unresolved here is determining whether pyodbc is the culprit in adding that spurious schema name. Would someone with a working pyodbc verify that it is by trying some direct-text SQL against a pyodbc DBAPI cursor? I would think that create table foo(id int) would do the trick. Watch the SQL that actually gets sent over the wire, and where the table ends up. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
