Ich habe django-pyodbc-azure für eine Weile unter Linux verwendet, zusammen mit pydobc, FreeTDS und unixODBC, um Django mit SQL Server 2014 zu verbinden. Ich habe dieses Problem mit einer Anwendung, die gut funktioniert hat, und bin Probleme beim Debuggen. Um das Problem zu reproduzieren, habe ich eine brandneue Django-App gestartet, um die Dinge einfach zu halten. Hier ist mein virtualenv:
%Vor%Hier ist meine Datenbankkonfiguration zum Herstellen einer Verbindung mit SQL Server:
%Vor%Und ich habe eine einfache models.py erstellt:
%Vor%Diese Einrichtung hat in einem ziemlich komplexen Django-Projekt funktioniert, das sich immer noch auf dieselbe Datenbank auswählt. Immer wenn ich versuche, ein UPDATE oder eine Migration durchzuführen, habe ich diesen Fehler erhalten:
%Vor% Der seltsame Teil ist, dass er die Tabelle in SQL Server ([home_testtemp]) erfolgreich erstellt und bei einem nicht erforderlichen Rollback zu einem Fehler zu kommen scheint. Irgendwelche Ideen zu den besten Möglichkeiten, dies weiter zu debuggen oder das Problem zu beheben? Wenn ich die SQL-Ausgabe von ./manage.py sqlmigrate home direkt für die Datenbank benutze, die mit diesem Benutzernamen und Passwort angemeldet ist, funktioniert es einwandfrei.
Vielen Dank im Voraus.
UPDATE 1: Dies ist kein guter Fix, aber es kommt herum, was anscheinend ein Problem mit einem Rollback ist, das aufgerufen wird, wenn es nicht sollte. Diese Änderung erfolgt um Zeile 389 von base.py in django-pyodbc-azure:
Das ist hässlich und beseitigt eine Schutzmaßnahme, sorgt aber dafür, dass die Dinge in der Zwischenzeit funktionieren. Ändern von base.py um Zeile 389 in django-pyodbc-azure:
%Vor%Offensichtlich immer noch nach einer tatsächlichen Lösung und nicht nach einem Hack und der eigentlichen Ursache.
UPDATE 2: Setzt die in UPDATE 1 oben vorgenommene Änderung auf den ursprünglichen django-pyodbc zurück. Ändern Sie dann in den EINSTELLUNGEN die tds_version in 7.0 oder 7.1 . Es klappt. Wenn Sie es in 7.2 oder 7.3 ändern, bricht es ab. Könnte dies ein Problem mit den neuen DATE-Feldern sein, die ab SQL Server 2008 verfügbar sind? So oder so, eine temporäre Lösung ist die Rückkehr zu TDS Version 7.1, und dies ist eindeutig nützliche Informationen für eine Lösung.
Da es unter 7.0 und 7.1 funktioniert, frage ich mich, ob Ihre SQL Server 2014-Datenbank auf die SQL Server 2000-Kompatibilitätsebene eingestellt ist, die Sie auf die Verwendung von TDS Version 7.1 oder niedriger beschränken würde.
Links:
Tags und Links python django sql-server pyodbc django-pyodbc-azure