Porting to Django Linux with SQL Server Backend

[robert brook]

The group has been developing locally with sqllite on Windows.

We are porting the installation to a Linux environment /windows sql server.

Looking for suggestions for database connectors from Linux to sql server 2014

using:

python3.3

django 1.7

I have installed a local copy of sql server to try and find a connector package

I have tried the following packages on my windows machine with a local copy of sql server

django-pyodbc-azure   -This worked after creating a local odbc connection

The following failed with a variety of errors.

django-pyodbc

pymssql

django-sqlserver

django-mssql

Any suggestions for the sql server connection for any of these would be appreciated.

Thanks in advance

[Michael Manfre]

It's hard to give constructive feedback without knowing any of the specific errors you encountered, but django-mssql only works on Windows. Depending on the error you encountered with pymssql, you could try django-pymssql (https://github.com/aaugustin/django-pymssql).

Regards,

Michael Manfre

[robert brook]

Sorry I guess I should have focused the question better.

I have a working connector on my windows machine using django-pyodbc-azure

I can and will use this connector on the new Linux installation.

Since I have never tested this on a Linux machine yet, I wanted to see if anyone had any successful experiences with this connector

or any other connector  on a Red Hat Linux box.

By the way I looked at the link below and the comments on the git page seem that they are lagging behind on developing this package with

the current releases of both python and django

Thanks

Bob

[Kelvin Wong]

I have a working system running Django 1.6/Python 2.7 on RHEL 7 connecting to MSSQL2012 SP 2 on Win Server.

On the Linux box we are installing this with Pip requirements:

 git+https://code.google.com/p/pyo...@3.0.7#egg=pyodbc

 django-pyodbc-azure==1.1.5

The local_settings.py contains:

DATABASES = {

    "default": {

        ...

        "HOST": "192.168.0.10",

        "PORT": "",

        "OPTIONS": {

            "driver": "FreeTDS",

            "dsn": "sqlserverdatasource",

            'host_is_server': True,

            'autocommit': True,

            'unicode_results': True,

            'extra_params': 'tds_version=8.0'

        }

    }

}

We are running the latest FreeTDS from 2011.

$ tsql -C

...

freetds v0.91

We've had quirky problems with it and a few mysterious segfaults on the application server from time to time. It does work for the most part, but the application isn't under any kind of load at the moment.

If I had a choice, I wouldn't run Django on MSSQL Server.

- K

[robert brook]

Thanks for your response.

I am in the process of porting this.  I am concerned that I really only have one potential option of pyodbc-azure in the event that there is a problem.

Unfortunately unless I reach a complete stumbling block I will use the pyodbc - azure connector to enable me to connect to sql server from Linux

At this point what I am trying to do is use sqlalchemy wherever I can in the views to improve functionality and performance.

And I will be using the built in ORM (pyodbc-azure) to log users on to take advantage of the built in functionality of the user model.

Any suggestions / comments to using this combination would be appreciated

[Kelvin Wong]

Your options are limited if you want to connect to a 2012 SQL Server. The azure driver is the only one that would work for us and we tested everything we could find.

K

[robert brook]

Thank you for your response.

I saw that you mentioned that you were getting seg faults

I noticed on a web site that there was an entry that might overcome that problem

http://www.kcaran.com/entries/technology/linux/linuxodbc.html

***************

sing Red Hat, you may get a ‘Segmentation Fault’ using DBI, even though connecting to the database works fine with tsql. If this happens, try setting the following environmental variable: PERL_DL_NONLAZY = 1 
Read this Usenet thread for more details

NOTE: This appears to be fixed.
https://rhn.redhat.com/errata/RHBA-2006-0319.html

***************

On Thursday, October 16, 2014 1:18:21 AM UTC-4, WongoBongo wrote: