Jean-Paul, thanks for the reply:
How do you tell the difference between a network error which prevented a statement from being executed by the SQL server and a network error which only prevented the response indicating that the statement was successfully executed from being returned to you? If you can't tell the difference, how do you ensure that you don't re-execute statements which modify the database causing corruption of your data?
Well, I was a bit cryptic in my description. Based on experience with SQL Server and experimentation with different conditions, I'm pretty sure I can tell from the exception data whether the statement completed successfully. You're right, though, I do need to be careful about this.
I've never used pyodbc, but presumably the exception indicates you're using the objects in a thread where they're not allowed to be used.
By tracing through the operation of adbapi, I figured out why I was getting that message when the network is down: Connection.reconnect does a ConnectionPool.disconnect followed by a ConnectionPool.connect, which does a dbapi.connect; this fails, since the network is still down. The exception is caught in _runInteraction, which tries to do a conn.rollback, which calls ConnectionPool.disconnect. Since there's no connection at this point, I get the "wrong connection" exception. The moral of the story seems to be that I need to rethink how to detect the difference between a "stale" connection with the network back up, and a network down condition. Another possibility would be to adapt adbapi to work in one-connection-per-operation mode, so there'd never be an open connection hanging around. (This sort of defeats the point of ConnectionPool, but the API of the module would be preserved.) -- Don Dwiggins Advanced Publishing Technology