>> Sure, but the drop is being issued in the correct default schema (dbo).
>No it's not. If I don't enable checkfirst the table is dropped, which >means both statements are issued on the wrong schema (considering that >the check is right). Ah OK I didn't get that from the previous messages. Then it sounds like the check is looking at the default schema, but the issued statements aren't using it. Looking at the code, I can see the explicit use of the default schema for table existence checks and table reflects, but no special treatment for normal SQL ops like SELECT/UPDATE/DELETE. The code assumes that these details will be handled by the default ansisql.py Dialect, which would then issue it's own checks for default schema by callbacks to get the default schema. But at least in the 0.3 branch, those calls are never made, the SQL generator just looks for the table.schema, which is presumably an explicit schema set in the metadata. Mike, are you watching this thread? Should ansisql recognize and use default schemas, or should the DB dialect somehow override the construction of the table name? >I'm going back and forth between both implementations, and am willing >to help a bit on mssql support. From time to time I try to see why a >unittest wouldn't pass and if I can see why I propose a patch. That is a very much appreciated effort; making unit tests pass for MSSQL is a big job. Rick --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
