patches for working with multiple-database version of django (on trunk)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. set up a django instance with multiple database support (currently on 
Django trunk, see http://docs.djangoproject.com/en/dev/topics/db/multi-db/)
2. use django-pyodbc as the connection for a non-default database.

What is the expected output? What do you see instead?

When you try to access the pyodbc database, you will be connected to the 
default database instead.  This causes issues with explicit table access, 
and breaks the hidden query in get_ss_ver.

What version of the product are you using? On what operating system?

Trunk on Windows.

Please provide any additional information below.

Patches (which have NOT been tested with using django-pyodbc as the default 
database or in a single-database configuration).  Note that this patch 
requires you to specify the database version in the settings.py file, near 
where you do the DSN configuration.  

Index: base.py
===================================================================
--- base.py     (revision 173)
+++ base.py     (working copy)
@@ -102,16 +102,18 @@
     def __init__(self, *args, **kwargs):
         super(DatabaseWrapper, self).__init__(*args, **kwargs)

+        self._ss_ver = 2000
         if 'DATABASE_OPTIONS' in kwargs:
             self.MARS_Connection = 
kwargs['DATABASE_OPTIONS'].get('MARS_Connect
ion', False)
             self.datefirst = kwargs['DATABASE_OPTIONS'].get('datefirst', 
7)
+            self._ss_ver = kwargs['DATABASE_OPTIONS'].get("ss_ver", 2000)

         self.features = DatabaseFeatures()
-        self.ops = DatabaseOperations()
+        self.ops = DatabaseOperations(self._ss_ver)
         self.client = DatabaseClient(self)
         self.creation = DatabaseCreation(self)
         self.introspection = DatabaseIntrospection(self)
-        self.validation = BaseDatabaseValidation()
+        self.validation = BaseDatabaseValidation(args[1])

         self.connection = None

Index: operations.py
===================================================================
--- operations.py       (revision 173)
+++ operations.py       (working copy)
@@ -4,17 +4,23 @@
 import time

 class DatabaseOperations(BaseDatabaseOperations):
-    def __init__(self):
-        self._ss_ver = None
+    def __init__(self, ss_ver):
+        # CCC:  initialize the superclass
+        BaseDatabaseOperations.__init__(self)
+        self._ss_ver = ss_ver

     def _get_sql_server_ver(self):
         """
         Returns the version of the SQL Server in use:
         """
+        # CCC: this should be moot, as it was set up at configuration 
time.
+        # But I will leave it anyway.
         if self._ss_ver is not None:
             return self._ss_ver
         else:
-            from django.db import connection
+            if connection is None:
+                from django.db import connection
+
             cur = connection.cursor()
             cur.execute("SELECT CAST(SERVERPROPERTY('ProductVersion') as 
varcha
r)")
             ver_code = int(cur.fetchone()[0].split('.')[0])
@@ -24,7 +30,7 @@
                 self._ss_ver = 2000
             return self._ss_ver
     sql_server_ver = property(_get_sql_server_ver)
-
+
     def date_extract_sql(self, lookup_type, field_name):
         """
         Given a lookup_type of 'year', 'month', 'day' or 'week_day', 
returns

Original issue reported on code.google.com by ccur...@gmail.com on 14 Jan 2010 at 3:31

[GoogleCodeExporter]

fixed in r174.

Original comment by vcc.ch...@gmail.com on 24 Jan 2010 at 7:46

• Changed state: Fixed

[GoogleCodeExporter]

It looks like the code change to permit the SS version to be added to the 
config file 
did not make it in this patch.  Is that intentional?  I ask because the query 
in 
get_ss_ver ("SELECT CAST(SERVERPROPERTY('ProductVersion') as varchar)") is 
throwing a 
syntax error when I run it through Django against SQL Server 2000.  (Strangely, 
it 
works fine when I run it through Management Studio and returns a value of 
"8.00.760".)

Original comment by ccur...@gmail.com on 18 Feb 2010 at 2:15