I'm having trouble connecting to a SQL Server database through python manage.py dbshell / loaddata.
I'm set up on Ubuntu with FreeTDS, unixODBC, pyodbc (3.0.7) and django-pyodbc from here:
https://github.com/lionheart/django-pyodbc/
I can successfully run syncdb and South migrations. However, when I try to run the dbshell or loaddata, I get this error:
[IM002][unixODBC][Driver Manager]Data source name not found, and no default driver specified
[ISQL]ERROR: Could not SQLConnect
I can connect from the command line using isql and tsql. Any ideas on what I'm missing?
So, I figured out the problem.
If you want to use dbshell or loaddata, you need to use a named DSN instead of just a host. I had this set up in /etc/freetds.conf, /etc/odbcinst.ini, and /etc/odbc.ini correctly, so tsql and isql were working.
I was using this default DATABASE in settings.py:
'ENGINE': 'django_pyodbc',
'NAME': 'db_name',
'USER': 'user_name',
'PASSWORD': 'pw',
'HOST': 'hostname.domain.com,1433',
'PORT': '1433',
'OPTIONS': {
'host_is_server': True,
'autocommit': True,
'unicode_results': True,
'extra_params': 'tds_version=7.2'
},
I had to change it to:
'ENGINE': 'django_pyodbc',
'NAME': 'db_name',
'USER': 'user_name',
'PASSWORD': 'pw',
'PORT': '1433',
'OPTIONS': {
'host_is_server': True,
'dsn': 'dsn_name',
'autocommit': True,
'unicode_results': True,
'extra_params': 'tds_version=7.2'
},
You will notice the first (broken) example uses a 'HOST', while the second (working) example uses a 'dsn' under 'OPTIONS."
Related
I'm running Django (1.8) off a Ubuntu server (Ubuntu 16.04.3 LTS), using VirtualEnv and Pip.
pip freeze
astroid==1.5.3
backports.functools-lru-cache==1.4
configparser==3.5.0
Django==1.8
django-mssql==1.8
django-pyodbc==1.1.1
django-pyodbc-azure==1.11.0.0
django-sqlserver==1.11
enum34==1.1.6
future==0.16.0
inflection==0.3.1
isort==4.2.15
lazy-object-proxy==1.3.1
mccabe==0.6.1
peewee==3.1.5
pkg-resources==0.0.0
psycopg2==2.7.3.1
pyad==0.5.15
pylint==1.7.4
pyodbc==4.0.19
PyPiwi==1.8
python-tds==1.8.2
pytz==2017.2
singledispatch==3.4.0.3
six==1.11.0
South==1.0.2
wrapt==1.10.11
I'm currently struggling with sqlserver_ado ENGINE and am using it because it seems to be the most popular, but am aware of django.db.backends.postgresql_psycopg2 and sql_server.pyodbc, and am willing to jump ship at the drop of a hat.
So my DATABASES definition looks like this:
'default': {
'NAME': 'DB_NAME',
'ENGINE': 'sqlserver_ado',
'HOST': 'HOSTNAME\\SQLEXPRESS',
'PORT': '56988',
'USER': 'mssql_name',
'PASSWORD': 'mssql_pw',}
Django runs with this information. Fantastic. But when I hit my function,
def my_custom_sql(self):
with connection.cursor() as cursor:
cursor.execute("SELECT * FROM [GM].[Acct]")
row = cursor.fetchone()
return row
I get an exception: When using DATABASE PORT, DATABASE HOST must be an IP address. If I try to change the host to an IP address, Django won't run, and spews this:
File "/home/jason/env/local/lib/python2.7/site-packages/sqlserver_ado/dbapi.py", line 183, in connect
import pythoncom
I've tried pip install pypipwin32.
When I run django using python3, I get ImportError: No module named 'sqlserver_ado'
If anyone is able to nudge me in the right direction that would be appreciated.
For the sake of completeness, here are some of my attempts with tsql, but again, my connection is constantly refused:
/etc/odbc.ini
[DARKTOWER_SQLEXPRESS]
Description=Test
Driver=FreeTDS
Database=DB
Servername=DARKTOWER\\SQLEXPRESS
port=56988
TDS_Version=7.2
/etc/odbcinst.ini
[ODBC]
Trace = Yes
TraceFile = /tmp/odbc.log
[FreeTDS]
Description = v0.91 with protocol v7.2
Driver = /usr/lib/x86_64-linux-gnu/odbc/libtdsodbc.so
Setup = /usr/lib/x86_64-linux-gnu/odbc/libtdsS.so
UsageCount = 1
/etc/freetds/freetds.conf
[DARKTOWER]
host = DARKTOWER\\SQLEXPRESS
port = 56988
tds version = 7.2
Got some success using these settings. Not a fan of having to use a domain account...
'default': {
'ENGINE': 'sql_server.pyodbc', #'sqlserver_ado', #'sql_server.pyodbc',
'HOST': 'DARKTOWER\\SQLEXPRESS',
'PORT': '56988',
'USER': 'DOMAIN\\Jason',
'PASSWORD': 'xxxxxxxxxxxx',
'NAME': 'DB',
'AUTOCOMMIT': True,
'OPTIONS':{
'driver': 'FreeTDS',
'host_is_server': True,
'extra_params': 'tds_version=7.2',},
}
I'm still interested in others' solutions.
Try using something like this:
'default': {
'ENGINE': 'sqlserver',
'HOST': 'aws2.myhost.com',
'PORT': '1433',
'USER': 'xxxxx',
'PASSWORD': 'nbxxxa$$sxxxxxts$$xxxx',
'NAME': 'MyDBName',
instead of what you have. I have the same sql pip entries as you, and that is how my settings.py looks when I connect to sql server
I have very annoying problem.
If I run my unit tests in Django with python manage.py jenkins environment=local
I get error:
Creating test database for alias 'default'...
Traceback (most recent call last):
...
django.db.utils.OperationalError: no such table: connectors_testex1
My test database is sqlite3, real database is postgres.
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql',
'NAME': CONFIG['database']['db'],
'USER': CONFIG['database']['user'],
'PASSWORD': CONFIG['database']['password'],
'HOST': CONFIG['database']['host'],
'PORT': CONFIG['database']['port'],
}
}
if 'test' or 'jenkins' in sys.argv:
DATABASES['default'] = {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': 'test',
}
Problem is that connectors_testex1 does not exist.
Even if I do
grep -r -i "connectors_testex1" /myproject/*
it doesn't found anything.
If I use same code on different machine (same git branch) it works normally.
what could be the problem?
To check if merge migrations are required, I can run manage.py makemigrations --check or manage.py makemigrations --dry-run
However, both of those require the database to be up. If it's not up, it will error out with something like
django.db.utils.OperationalError: (2002, "Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)")
Theoretically, since a merge migration issue occurs because of two migration with the same parent, you don't need the database instance to be up to check for this condition.
I need this because I want my CI to check for this case. I can spin up a docker database but it's extra work for something that's not even logically dependent. I'm also sure there are people out there who are interested in checking for this in their CI, who don't want to deal with containerization.
Has anyone found an easy way to to check for migration merge conflicts without needing a database up?
Since the goal is to run makemigrations --dry without a mysql database up, the easiest workaround I came up with is to create a new settings file called makemigrations_settings.py that overrides the database to use the builtin sqlite database.
from your_main_settings import *
DATABASES = {
'default' : {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': 'database_name',
'USER': 'your_mom',
'PASSWORD': '',
'HOST': '',
'PORT': '',
},
}
Then you can run
python manage.py makemigrations --check --settings yourapp.makemigrations_settings
Alternatively, you can less elegantly do something like
if (sys.argv[0:2] == ['manage.py', 'makemigrations']
and ('--dry-run' in sys.argv or '--check' in sys.argv)):
DATABASES = {
'default' : {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': 'database_name',
'USER': 'your_mom',
'PASSWORD': '',
'HOST': '',
'PORT': '',
}
}
I have tried using
pymysql
mysql-client
mysql-connector-pyhton
and various other ways stated in this question but still I am not able to use MySql as my database.
Whenever I try to do run it shows below error message.
raise ImproperlyConfigured("Error loading MySQLdb module: %s" % e)
django.core.exceptions.ImproperlyConfigured: Error loading MySQLdb module: No module named 'MySQLdb'
I have tried these two Database configuration in my setting.py file
Setting 1: This works with python 2.7
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'user_db',
'USER': 'ecom',
'PASSWORD': 'ecom#123',
'HOST': 'localhost', # Or an IP Address that your DB is hosted on
'PORT': '',
}
}
error message :
`raise ImproperlyConfigured("Error loading MySQLdb module: %s" % e)
django.core.exceptions.ImproperlyConfigured: Error loading MySQLdb module: No module named 'MySQLdb'`
Setting 2: as suggested in this question's answer
DATABASES = {
'default': {
'NAME': 'mydatabase',
'ENGINE': 'mysql.connector.django',
'USER': 'myuser',
'PASSWORD': 'secretpassword',
'OPTIONS': {
'autocommit': True,
},
}
}
error message :
Try using 'django.db.backends.XXX', where XXX is one of:
'mysql', 'oracle', 'postgresql', 'sqlite3'
Error was: No module named 'mysql'
Still I am not able to use mysql as backend can anyone please let me know what I am doing wrong or is it even possible with python 3.4.3?
I would be really thankful for your help and guidance.
I use django-pyodbc on Django 1.6.1
when I run manage.py syncdb, everything is fine.
I use 2 database setttings in Django to read some data from my legacy database, when I what to read the data from a model name T_AllStation:
all_t_station = T_AllStation.objects.using('SQL_Server').all()
An error is raised:
DatabaseError at /company/get_station_info
('42S22', "[42S22] [Microsoft][ODBC SQL Server Driver][SQL Server]\xc1\xd0\xc3\xfb 'id' \xce\xde\xd0\xa7\xa1\xa3 (207) (SQLExecDirectW)")
Request Method: GET
Request URL: http://127.0.0.1:8000/company/get_station_info
Django Version: 1.6.1
Exception Type: DatabaseError
Exception Value:
('42S22', "[42S22] [Microsoft][ODBC SQL Server Driver][SQL Server]\xc1\xd0\xc3\xfb 'id' \xce\xde\xd0\xa7\xa1\xa3 (207) (SQLExecDirectW)")
Exception Location: E:\VirtualEnvs\EnvMonitor\lib\site-packages\django_pyodbc\base.py in execute, line 416
Python Executable: E:\VirtualEnvs\EnvMonitor\Scripts\python.exe
Python Version: 2.7.2
What does the string \xc1\xd0\xc3\xfb 'id' \xce\xde\xd0\xa7\xa1\xa3 (207) mean ?
Try making your configuration file use options like this, to account for Unicode:
DATABASES = {
'default': {
'ENGINE': 'django_pyodbc',
'NAME': 'db_name',
'USER': 'db_user',
'PASSWORD': 'your_password',
'HOST': 'database.domain.com,1433',
'PORT': '1433',
'OPTIONS': {
'host_is_server': True,
'autocommit': True,
'unicode_results': True,
'extra_params': 'tds_version=8.0'
},
}
}
(You're on Windows, so you don't need the tds_version, but it can't hurt so your config is portable to Linux.)