I have an azure sql server instance containing a database which has a hyphen in its name like "database-name".
I am trying to connect via a python script and having some issues with it.
In the script when I use the connection string like this:
"Driver={ODBC Driver 18 for SQL Server};Server=serveraddress;Database=database-name;UID=username;PWD=password;"
I get the following error:
Incorrect syntax near 'name'.
I figured this may be caused by the hyphen and changed the connection string to this instead:
"Driver={ODBC Driver 18 for SQL Server};Server=serveraddress;Database=[database-name];UID=username;PWD=password;"
But I get an error like this:
Cannot open database "[database-name]" requested by the login. The login failed.
however I am able to login with the same user from SSMS.
Can this be permission related issue?
I tried to reproduce your scenario on my end and got results like the below:-
I created one Azure SQL server and database both with hyphen in their names like below:-
Make sure you add your client IP access to your Azure SQL database like below:-
I populated Azure SQL Database with one table and its entities.
Tried the below code to connect Azure SQL DB with python, Make sure your connection string format is correct as per the code below:-
You can validate the connection string from your Azure Portal like below:-
Code:-
import pyodbc
conn = pyodbc.connect('Driver={ODBC Driver 17 for SQL Server};'
'Server=tcp:valley-server.database.windows.net,1433;'
'Database=valley-db;'
'Uid=siliconserver;'
'Pwd=xxxxxx#123')
cursor = conn.cursor()
cursor.execute('SELECT * FROM StudentReviews')
for i in cursor:
print(i)
cursor.close()
conn.close()
SQL command executed successfully by connecting to Azure-SQL DB. Make sure the ODBC package is installed in your machine from where you’re executing the code. And the server or Database name has correct spelling or syntax.
Recently, one of our servers was migrated to 3-node cluster from a pylon server. The connection string below is what I used previously via python and pyodbc and never had any issues.
server = 'test_server'
database = 'test_db'
cnxn = 'DRIVER={SQL Server};SERVER='+server+';DATABASE='+database+';Trusted_Connection=yes'
With the new server I started receiving time out errors. So i thought I had to add MultiSubnetFailover to the connection string such as the following
server = 'test_server'
database = 'test_db'
cnxn = 'DRIVER={SQL Server};SERVER='+server+';DATABASE='+database+';Trusted_Connection=yes;MultiSubnetFailover=True'
However, I am still receiving a time out error as well as an additiaonl error seen below
[Microsoft][ODBC SQL Server Driver]Login timeout expired (0) (SQLDriverConnect); [HYT00] [Microsoft][ODBC SQL Server Driver]Invalid connection string attribute (0)
Does pyodbc support MultiSubnetFailover? I couldn't find documentation one way or another.
If so, how do I implement it? On the other side, if it does not, how would i go about connecting?
Lastly, should I use the IP address instead?
The ancient SQL Server ODBC driver that ships with Windows doesn't support MultiSubnetFailover. I suggest you move to a modern driver or have your DBA set RegisterAllProvidersIP to zero to support down level clients.
In the interim, you could specify the current listener IP address or the host name of the current primary node. However, that will fail if the primary is failed over to a secondary node on a different subnet.
How can I connect to a sql/mp or sql/mx database on Nonstop using python.?
i have followed this to get the connection established to HP nonstop database, I am getting error as driver DRIVER={NonStop ODBC/MX 3.6} is not found.
Help is appreciated.
To connect the NonStop sql or for any relevant databases, a ODBC or JDBC driver is required.
From my experience JDBC works with JAVA only thought there are pyodbc and other python libs are available( they didn't work for me and they internally depends on java.)
Better to do it in java. In my case I called the java class from python using os level commands and result stored in excel which is read from python again.
I am Working on Ubuntu 18.04 when I am using Pyodbc connection with SQL Anywhere 17 Driver to connect to a Sybase DB, while trying to establish connection my Jupyter notebook Dies.
The expectation is, I should be able to run this code in Ubunt and connect to a Sybase DB.
I can connect and run query from Windows without problems(using DSN).
I have been working with other driver and SQL Server, MySQL and MariaDB and I have not encountered any problems.
I believe connection to Sybase database needs SQLANYWHERE DRVIER.
If Someone knows how get the connection string which is passed from pyodbc to the server when I use a DSN?(maybe this could give me an idea to know what i'm doing wrong).
Some advice?
Code run in windows without problems
import pyodbc
import pandas as pd
cnxn = pyodbc.connect("DSN=RevDSN")
print(cnxn)
data = pd.DataFrame(pd.read_sql_query(query, cnxn))
cnxn.close()
Since I didn't find a good explanation I am putting this here.
I installed the client from
https://archive.sap.com/documents/docs/DOC-35857
then followed the basic instructions from
https://wiki.scn.sap.com/wiki/display/SQLANY/Installing+SQL+Anywhere+17+on+Ubuntu+14.04
The ODBC Client will not ask for the keys
As the documentation says the important part is running the sa_config.sh and making sure that the exports happen.
Lastly edit the /etc/odbcinst.ini file and add the driver.
For example
[SQL Anywhere 17]
Driver=/opt/sqlanywhere17/lib64/libdbodbc17.so
TDS_Version=5.0
UsageCount=1
Then I used this connection string
import pyodbc
cnxn = pyodbc.connect('Driver={SQL Anywhere 17};LINKS=TCPIP{HOST=<server ip here>};PORT=2638;UID=admin;PWD=<password here>;ENG=<engine name>;DBN=<database name>;')
cursor = cnxn.cursor()
cursor.execute("select top 10 * from dba.<table name>")
for row in cursor:
print(row)
And it worked.
I have a python script that I have made and developed an .exe with Pyinstaller that uses python's pyodbc library to query and looks like the fake code below. It works on my computer perfectly. I tried to share my .exe with a couple co-workers, who I have double-checked have access to query our databases within Excel after providing them login information. However, they are not able to access our database from within my python .exe.
After testing once, I know that they are unable to access, because the .exe I created outputted error (No suitable driver found. Cannot connect.) as you can see in the code below, because it could not find ODBC Driver 17 for SQL Server on the colleague's computer. I believe Excel uses PowerQuery, so it doesn't have a reliance on an ODBC Driver, but python will require the driver. My question is this -- should simply installing the ODBC Driver 17 for SQL Server from this link work? https://www.microsoft.com/en-us/download/details.aspx?id=56567
The user doesn't have admin rights to download the driver (and I can't test this myself on another computer) and I have limited time and and access to IT resources; otherwise, I would troubleshoot with the user myself, so I'm eager to hear if anyone has any experience with this or has found a similar post/documentation that could be helpful to me. Again, the code is below for reference, but I don't need assistance with that. I need to explain to IT what I need them to do for the users, which is why I was wondering if Microsoft® ODBC Driver 17 for SQL Server® - Windows will be enough.
import pandas as pd
import pyodbc
#Connection and credentials
driver_name = ''
driver_names = [x for x in pyodbc.drivers() if x.endswith(' for SQL Server')]
driver_names
if driver_names:
driver_name = driver_names[-1]
if driver_name:
conn_str = f'''DRIVER={driver_name};SERVER='''
else:
print('(No suitable driver found. Cannot connect.)')
server = '111.111.11.111'
database = 'database'
username = 'username'
password = 'password'
cnxn = pyodbc.connect(conn_str+server+';DATABASE='+database+';UID='+username+';PWD='+ password)
try:
account_id_input = input("Select Account ID: ").strip()
print("Confirming Account ID...")
#SQL Query
df = pd.read_sql_query("""
Select [Account ID], [Year-Month], [Revenue] from database.dbo.tblaccount
""",
cnxn, params=[account_id_input]
)
print("CONFIRMED")
else: print("Incorrect ID or database connection error")
df.to_csv(f'{account_id_input}_data.csv', index=False)
In short, yes ODBC driver would be only additional download required for pyodbc.
PyODBC is an open-ended Python DB-API that accepts any compliant ODBC driver from any data source (Oracle, SQL Server, PostgreSQL, SalesForce, Quickbooks, etc.). ODBC drivers serve as a middle-layer between client (i.e., Python) and database server and, like any software, they can be developed by proprietary vendors (e.g., Oracle, Microsoft), open-source developers/groups, or third-parties. In addition, ODBC is a recognized technology among many platforms like Excel and languages.
Unlike other Python DB-APIs (pymysql, cxOracle, psycopg2), pyodbc as you recognize has one requirement: the specified ODBC driver in code must be installed beforehand on the client machine (not simply the Python library installed). By the way, this is very similar to JDBC drivers with Python's jaydebeapi and Microsoft does maintain JDBC drivers for SQL Server.
Your colleagues receive the following error:
No suitable driver found. Cannot connect.
because that specific ODBC driver is not installed on their machines but is installed on your machine. Have them check what versions are available to them with the command:
pyodbc.drivers()
As background Microsoft maintains multiple ODBC drivers (of varying versions that are backwards compatible) for Windows, Linux, and MacOS machines. Because MS Excel does not have any native database layer, it usually connects with ODBC or OLEDB but with a library like DAO or ADO (counterpart to Python's library, pydobc). Possibly, your other colleagues maintain other versions such as:
'ODBC Driver 11 for SQL Server'
'ODBC Driver 13 for SQL Server'
'SQL Server'
'SQL Native Client'
'SQL Server Native Client 11.0'
With that said, if you are going to circulate your code integrated into an executable to other users, do not hard-code any ODBC credentials since as you demonstrate, CPU environments vary considerably. Instead, consider below three solutions:
Data Source Name: Create a Data Source Name (DSN) individually tailored to each user machine that can vary between different drivers, servers, username, passwords, etc.
cnxn = pyodbc.connect(dsn="myDatabase")
Configuration File: Use configuration files like yaml or json with all credentials listed in a secured folder and then integrated into connection. Many online tutorials on this.
YAML
db:
driver: 'ODBC Driver Name'
server: '111.111.11.111'
database: 'database'
username: 'username'
password: 'password'
Python
import yaml
with open('file.yaml') as f:
db_creds = yaml.load(f)
...
cnxn = pyodbc.connect(driver=db_creds['driver'], host=db_creds['server'],
uid=db_creds['username'], pwd=db_creds['password'],
database=db_creds['database'])
Environment Variables: Use environment variables permanently or temporarily set on user's machine before connection.
import os
...
cnxn = pyodbc.connect(driver = os.environ.get('MSSQL_DRIVER'),
host = os.environ.get('MSSQL_SERVER'),
uid = os.environ.get('MSSQL_USER'),
pwd = os.environ.get('MSSQL_PWD'),
database = os.environ.get('MSSQL_DB'))
Browse the web for documentation, tutorials, blogs, even other SO posts on how to troubleshoot. Above are simple examples that may need adjustment.
In short, the answer to this question turned out to be "Yes", but I am not deleting as this could be beneficial and useful for people who are researching how to share python/SQL .exe's with other users similar to how you might share an Excel Macro.
Assuming the user is on our company network, the only requirements were that the user:
1) downloads my python .exe file that utilizes the libraries: a) pyodbc and b) pandas
2) downloads an ODBC Driver for SQL Server, depending on your company's SQL Server setup. In my case, I had the user download ODBC Driver 17 for SQL Server: https://www.microsoft.com/en-us/download/details.aspx?id=56567
This means that they don't have to fully install SQL Server, just the driver!