I'm working on a script to automate a file load procedure. So, naturally I need to perform some stored procedures that already exist. I'm using pyodbc to connect to my database. I can SELECT perfectly fine from the database, but when I try to execute from the database I get this error:
pyodbc.ProgrammingError: ('42000', '[42000] [Microsoft][SQL Server Native Client 10.0]
Syntax error, permission violation, or other nonspecific error (0) (SQLExecDirectW)')
I can't figure out what the problem here is - the user has full DB admin permissions, the syntax is correct based off what the pyodbc official documentation says.
print("Executing SP")
conn.execute('{EXEC TEMP.s_p_test}')
print("SP Executed.")
Here, TEMP is the schema for the type of stored procedure in that specific database. I.e., it's the full name of the stored procedure. I feel like it's probably something stupidly obvious that I'm just missing.
I tried a couple of things to fix it. As #Brian Pendleton suggested, I had tried to change from an explicit database user defined via UID and PWD to trusted_connection=True. Unfortunately that did not change anything.
However, out of curiosity I decided to see what taking the curly braces out of the function call would do. The execution worked immediately and produced the desired output. It would seem that the documentation at pyodbc's wiki either shows bad examples or I found a bug I don't know how to replicate because I don't know what makes my situation abnormal.
Or, in other words, instead of
conn.execute('{EXEC TEMP.s_p_test}')
I used
conn.execute('EXEC TEMP.s_p_test')
Related
A student of mine is partaking on a piece of coursework where they create a small program / artefact and they have chosen to link Python with a database using pyodbc.
So far he can successfully connect and if he uses a select * from statement and then fetchall he can print out the whole database. But naturally to extend this work he wants to be able to filter results using where but it doesn't seem to work as intended and my experience in this is very limited.
For example the code:
cursor.execute("select * from Films where BBFC = '12'")
Gives this error
pyodbc.Error: ('07002', '[07002] [Microsoft][ODBC Microsoft Access
Driver] Too few parameters. Expected 1. (-3010) (SQLExecDirectW)')”
It is a database of films and wants to filter it by age rating (the bbfc column). I have taken a look myself and cant seem to fix the issue so any help or guidance would be massively appreciated.
The problem here might be some spelling mistakes or maybe a case senstive field name or table name. Would you be able to make sure that 'Films' and 'BBFC' are spelt correctly and match the DB?
I am getting the error
django.db.utils.OperationError: FATAL:database "/path/to/current/project/projectname/databasename" does not exist.
I have accessed the database both manually through psql, as well as through pgadmin4, and have verified in both instances that the database does exist, and I have verified that the port is correct.
Im not sure why I cant access the database, or why it would say the database cannot be found.
According to pgAdmin4, the database is healthy, and it is receiving at least 1 I/O per second, so it can be read and written to by...something?
I have installed both the psycopg2 and the psycopg2-binary just to be safe.
I figured out the answer, or at least I do believe I did. It was a two part problem.
Part of it was I left os.path.join(base_dir...) included as part of the '' name section.
The other was I used an "#" character as part of my password. Once I changed the password, and I removed the os.path.join(base_dir...) portion, it worked.
I am using Django for an application that uses a simple filtering system. I want the filter to test if the title of my model contains a query string.
The code, stripped down, looks like this:
cards = Card.objects.filter(title__icontains=query)
print cards.query
which returns the following query (again, unnecessary stuff is stripped):
SELECT [...] FROM `ygo_card_card`
WHERE `ygo_card_card`.`title` LIKE %dark%
Which returns no results, even though it should. When I run this query manually, I get
SQL Error (1064): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '%dark%' at line 1
If I wrap the %dark% part between apostrophes ('%dark%') when running manually, it works as expected. It seems to me that Django creates an incorrect query. Is this a bug or something that I can control by settings?
Any search returns irrelevant results, because the related keywords are too generic.
I use Django 1.6.5 and MySQL 5.5.38, running on Ubuntu Server 14.04 LTS.
The response is quite simple: I misinterpreted the problem.
The issue comes from an underlying problem: the MySQL LIKE statement is case-sensitive or insensitive depending on the collation and the Django filter used (icontains or contains) has no effect in the outcome. You can see this bug ticket for more information.
As Daniel Roseman pointed out, the .query property is not reliable, as the query is further processed by the database driver. This led me to believe that Django created a wrong query, while in fact it simply created a case-sensitive search that should have been case-insensitive, hence the lack of results.
In the end, the issue was resolved by changing the collation on columns, tables and the database.
I'm working in a environment with a very poorly managed legacy Paradox database system. (I'm not the administrator.) I've been messing around with using pyodbc to interact with our tables, and the basic functionality seems to work. Here's some (working) test code:
import pyodbc
LOCATION = "C:\test"
cnxn = pyodbc.connect(r"Driver={{Microsoft Paradox Driver (*.db )\}};DriverID=538;Fil=Paradox 5.X;DefaultDir={0};Dbq={0};CollatingSequence=ASCII;".format(LOCATION), autocommit=True, readonly=True)
cursor = cnxn.cursor()
cursor.execute("select last, first from test")
row = cursor.fetchone()
print row
The problem is that most of our important tables are going to be open in someone's Paradox GUI at pretty much all times. I get this error whenever I try to do a select from one of those tables:
pyodbc.Error: ('HY000', "[HY000] [Microsoft][ODBC Paradox Driver] Could not lock
table 'test'; currently in use by user '(unknown)' on machine '(unknown)'. (-1304)
(SQLExecDirectW)")
This is, obviously, because pyodbc tries to lock the table when cursor.execute() is called on it. This behavior makes perfect sense, since cursor.execute() runs arbitary SQL code and could change the table.
However, Paradox itself (through its gui) seems to handle multiple users fine. It only gives you similar errors if you try to restructure the table while people are using it.
Is there any way I can get pyodbc to use some sort of read-only mode, such that it doesn't have to lock the table when I'm just doing select and such? Or is locking a fundamental part of how it works that I'm not going to be able to get around?
Solutions that would use other modules are also totally fine.
Ok, I finally figured it out.
Apparently, odbc dislikes Paradox tables which have no primary key. You cannot update tables with no primary key under any circumstances, and you cannot read from tables with no primary key unless you are the only user trying to access that table.
Unrelatedly, you get essentially the same error messages from password-protected tables if you don't supply a password.
So I was testing my script on two different tables, one of which has both a password and a primary key, and one of which had neither. I assumed the error messages had the same root cause, but it was actually two different problems, with different solutions.
There still seems to be no way to get access to tables without primary keys if they are open in someone's GUI, but that's a smaller issue.
Make sure that you have the latest version of pyobdc (3.0.6)here, according to them, they
Added Cursor.commit() and Cursor.rollback(). It is now possible to use
only a cursor in your code instead of keeping track of a connection
and a cursor.
Added readonly keyword to connect. If set to True, SQLSetConnectAttr
SQL_ATTR_ACCESS_MODE is set to SQL_MODE_READ_ONLY. This may provide
better locking semantics or speed for some drivers.
Fixed an error reading SQL Server XML data types longer than 4K.
Also, i have tested this on a paradox server using readonly and it does works.
Hope this helps!
I just published a Python library for reading Paradox database files via the pxlib C-library: https://github.com/mherrmann/pypxlib. This operates on the file-level so should also let you read the database independently of who else is currently accessing it. Since it does not synchronize read/write accesses, you do have to be careful though!
I am writing some data into Mysql database
one of the attribute is a link for example : "http://dbpedia.org/resource/Madigan%27s_Millions"
for some insertion there is an error: error is
Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 's Millions',"http://dbpedia.org/resource/Madigan%27s_Millions"
I am suspecting that this error is coming because of the % operator in the link.
It is coming into a variable from a website and then it is suppose to enter in the database using SQL
Could somebody tell me, if I am thinking right what is apt solution for resolving it?in p
Your MySQL is not having a problem with %, but with an apostrophe. Check again what exactly you're inserting (I'm pretty sure it isn't what you thought it was) by printing to stderr and inspecting the server logs, or by using your framework's logging mechanism. If I'm right, use the mysql escape function or parametrized statements to convert your ' into \' (details)