(Django multi-database framework: http://docs.djangoproject.com/en/dev/topics/db/multi-db/)

Currently the _get_sql_server_ver() function in DatabaseOperations uses django.db.connection to query the SQL Server version. django.db.connection uses the default database, so this doesn't work if we're querying from a non-default database.

I think the fix for this is fairly easy.. I've been able to hack bits of it to work by passing in the 'connection' parameter to this function.

Eg. "self.connection.ops.sql_server_ver < 2005" becomes "self.connection.ops._get_sql_server_ver(self.connection) < 2005".

I attempted to patch it using your suggestion, but my QuerySets are always returning an empty list even though the database is populated. This occurs with or without the QuerySet.objects.using clause. The same QuerySets pointing to the same database work well when just using a single database. There must be something else going on.

I had mistyped _sql_server_version instead of _get_sql_server_version. The following patch for me is working against the Django trunk (12398) and two MSSql2008 databases from Linux using FreeTDS.

I should note that my "default" database was a MySQL database that I connected to with 'django.db.backends.mysql'. I did not try to syncdb to the MSSql databases.

There are other places where the _get_sql_server_version() call causes problems--especially when accessed via the sql_server_ver property since those cases cannot pass "connection". DatabaseOperations.field_cast_sql() is one such case.

You're right. My patch doesn't solve the whole problem. Perhaps the best way to solve this is to specify the version in DATABASE_OPTIONS. I'm not sure that a backend should be querying to find out the version on the fly anyway.

Actually, I think a better solution is to do what the Postgres backend does. The DatabaseOperations object in the Postgres backend also needs to know the database version in order to perform some database specific functions (sql_flush for example).

The Postgres solution is to pass the connection object to the DatabaseOperations constructor. This would solve the problem we have in operations.py where we have to import the connection and we are getting the default connection. We should never need to import the connection because it is part of the object.

Here's my updated patch to pass the connection object along as I suggested in comment

6. It passed my preliminary tests, but I haven't tested it widely yet.

I'm successfully using this for a read only model in a production app, along with the patch submitted for issue #76 with no problems. Thanks! I hope this makes it into the trunk soon!

I came to the same conclusion and applied basically the same patch. Been working nicely for me :)

It's working for me! Thank you!

Fixed in revision 180, thanks.