django-pyodbc-azure回滚错误与先前的工作配置-第389行

Question

我在Linux上使用django-pyodbc-azure已经有一段时间了，同时还使用pydobc、FreeTDS和unixODBC连接Django到Server 2014。我在一个运行良好的应用程序中遇到了这个问题，并且在调试它时遇到了困难。为了重现这个问题，我开发了一个全新的Django应用程序来保持简单。这是我的虚拟者：

(azuretest)[vagrant@vagrant azuretest]$ pip freeze
Django==1.8.6
django-pyodbc-azure==1.8.3.0
pyodbc==3.0.10

下面是连接到Server的数据库配置：

DATABASES = {
    'default': {
        'ENGINE': 'sql_server.pyodbc',
        'HOST': 'myserver.com',
        'PORT': '1433',
        'NAME': 'my_db',
        'USER': 'my_db_user',
        'PASSWORD': 'mypw',
        'AUTOCOMMIT': True,
        'OPTIONS': {
            'driver': 'FreeTDS',
            'autocommit': True,
            'unicode_results': True,
            'host_is_server': True,
            'extra_params': 'tds_version=7.2',
        },
    },
}

我创建了一个简单的models.py：

class TestTemp(models.Model):
    tempdate = models.DateField()

这个设置在一个相当复杂的Django项目中运行良好，这个项目仍然可以选择到同一个数据库。但是，每当我尝试进行更新或迁移时，我都会得到以下错误：

(azuretest)[vagrant@vagrant azuretest]$ ./manage.py migrate home
Operations to perform:
  Apply all migrations: home
Running migrations:
  Rendering model states... DONE
  Applying home.0001_initial...Traceback (most recent call last):
  File "/home/vagrant/.virtualenvs/azuretest/lib/python3.4/site-packages/sql_server/pyodbc/base.py", line 389, in _set_aut
ocommit
    self.connection.rollback()
pyodbc.Error: ('HY000', 'The driver did not supply an error!')

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "./manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/home/vagrant/.virtualenvs/azuretest/lib/python3.4/site-packages/django/core/management/__init__.py", line 354, in
 execute_from_command_line
    utility.execute()
  File "/home/vagrant/.virtualenvs/azuretest/lib/python3.4/site-packages/django/core/management/__init__.py", line 346, in
 execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/home/vagrant/.virtualenvs/azuretest/lib/python3.4/site-packages/django/core/management/base.py", line 394, in run
_from_argv
    self.execute(*args, **cmd_options)
  File "/home/vagrant/.virtualenvs/azuretest/lib/python3.4/site-packages/django/core/management/base.py", line 445, in exe
cute
    output = self.handle(*args, **options)
  File "/home/vagrant/.virtualenvs/azuretest/lib/python3.4/site-packages/django/core/management/commands/migrate.py", line
 222, in handle
    executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
  File "/home/vagrant/.virtualenvs/azuretest/lib/python3.4/site-packages/django/db/migrations/executor.py", line 110, in m
igrate
    self.apply_migration(states[migration], migration, fake=fake, fake_initial=fake_initial)
  File "/home/vagrant/.virtualenvs/azuretest/lib/python3.4/site-packages/django/db/migrations/executor.py", line 154, in a
pply_migration
    self.recorder.record_applied(migration.app_label, migration.name)
  File "/home/vagrant/.virtualenvs/azuretest/lib/python3.4/site-packages/django/db/migrations/recorder.py", line 67, in re
cord_applied
    self.migration_qs.create(app=app, name=name)
  File "/home/vagrant/.virtualenvs/azuretest/lib/python3.4/site-packages/django/db/models/query.py", line 348, in create
    obj.save(force_insert=True, using=self.db)
  File "/home/vagrant/.virtualenvs/azuretest/lib/python3.4/site-packages/django/db/models/base.py", line 734, in save
    force_update=force_update, update_fields=update_fields)
  File "/home/vagrant/.virtualenvs/azuretest/lib/python3.4/site-packages/django/db/models/base.py", line 759, in save_base

    with transaction.atomic(using=using, savepoint=False):
  File "/home/vagrant/.virtualenvs/azuretest/lib/python3.4/site-packages/django/db/transaction.py", line 186, in __enter__

    connection.set_autocommit(False)
  File "/home/vagrant/.virtualenvs/azuretest/lib/python3.4/site-packages/django/db/backends/base/base.py", line 295, in se
t_autocommit
    self._set_autocommit(autocommit)
  File "/home/vagrant/.virtualenvs/azuretest/lib/python3.4/site-packages/sql_server/pyodbc/base.py", line 390, in _set_aut
ocommit
    self.connection.autocommit = autocommit
  File "/home/vagrant/.virtualenvs/azuretest/lib/python3.4/site-packages/django/db/utils.py", line 98, in __exit__
    six.reraise(dj_exc_type, dj_exc_value, traceback)
  File "/home/vagrant/.virtualenvs/azuretest/lib/python3.4/site-packages/django/utils/six.py", line 658, in reraise
    raise value.with_traceback(tb)
  File "/home/vagrant/.virtualenvs/azuretest/lib/python3.4/site-packages/sql_server/pyodbc/base.py", line 389, in _set_aut
ocommit
    self.connection.rollback()
django.db.utils.Error: ('HY000', 'The driver did not supply an error!')

奇怪的是，它成功地在Server (home_testtemp)中创建了表，并且似乎在不必要的回滚中出错。关于进一步调试或修复问题的最佳方法，有什么想法吗？当我直接针对使用这个用户名和密码登录的数据库运行./manage.py sqlmigrate home输出时，它工作得很好。

提前谢谢。

更新1:这不是一个很好的修复方法，但在不应该调用回滚的情况下解决了一个问题。这个更改是围绕django-pyodbc-azure中的base.py第389行进行的：

这是丑陋的，摆脱了一个保障，但使事情在此期间运作。在django-pyodbc-azure中修改第389行周围的base.py：

def _set_autocommit(self, autocommit):
        self.connection.commit()

#        with self.wrap_database_errors:
#            if autocommit:
#                self.connection.commit()
#            else:
#                self.connection.rollback()
#            self.connection.autocommit = autocommit

显然，仍然在寻找一个实际的修复，而不是黑客和根本原因。

更新2:将上面更新1中所做的更改退回到原来的django-pyodbc。然后在设置中，将tds_version更改为7.0或7.1。它起作用了。如果将其更改为7.2或7.3，则会破坏。这可能是Server 2008中可用的新日期字段的问题吗？无论哪种方法，临时解决方案都是恢复到TDS版本7.1，这显然是关于修复的有用信息。

Answer 1

一个新版本的django-pyodbc-azure已经出版，为我修复了这个问题(谢谢，Michaya)。要修复它，只需升级：

pip install django-pyodbc-azure==1.8.6

如果需要，...and会更新您的需求文件。详细信息：https://github.com/michiya/django-pyodbc-azure/issues/46

Answer 2

因为它在7.0和7.1上工作，所以我想知道您的SQL Server 2014数据库是否设置为SQL Server 2000兼容性级别，这将限制您使用TDS版本7.1或更低版本。

链接：

TDS版本

产品行为