Why fetchall always results in `None`? - python

Here are data in MySQL databaseļ¼š
python3 tableļ¼šusers_info
But when i use fetchall to get all data in tables it always return none!!
I really really dont konw how to fix it,can someone has met this problem?
the followings are the code files.
encapsulation.py
import MySQLdb
class mysql_encapsulation(object):
def __init__(self,host,port,user,passwd,db,charset):
self.host = host
self.port = port
self.user = user
self.passwd = passwd
self.db = db
self.charset = charset
def open(self):
self.conn = MySQLdb.connect(host=self.host,port=self.port,user=self.user,passwd=self.passwd,db=self.db,charset=self.charset)
self.cursor = self.conn.cursor()
def close(self):
self.cursor.close()
self.conn.close()
def operate(self,sql,params):
try:
self.open()
self.cursor.execute(sql,params)
self.conn.commit()
print(' operate ok')
self.close()
except Exception,e:
print(e.message)
self.conn.rollback()
def get_result_set(self,sql,params=[]):
result=None
try:
self.open()
self.cursor.execute(sql,params)
result = self.cursor.fetchall()
self.close()
except Exception,e:
print('error!')
print(e.message)
return result
use.py(problem in this file)
#coding=utf-8
from encapsulation import *
mysql = mysql_encapsulation(port=3306,host='localhost',user='root',passwd='mysql',
db='python3',charset='utf8')
sql='select id,name from users_info where id=3'
result=mysql.get_result_set(sql)
print (result)

The problem happens in this method;
def get_result_set(self,sql,params=[]):
result=None
try:
self.open()
self.cursor.execute(sql,params)
result = self.cursor.fetchall()
self.close()
except Exception,e:
print('error!')
print(e.message)
return result
One of the first 3 lines in the try block (self.open / self.cursor.exec / result = self.cursor.fetch) generate an error, which you are then catching in the except block and (you can see that it prints "error!"). That's why the result always stays in it's default None value. Remove the except block and it will tell you what kind of error occured.
You should almost never catch the bare Exception but instead catch specific kinds of exception and handle each of them correctly, this problem is a prefect example why.
The error in question probably happens because in your SQL query you are selecting id and name, when the columns in your table are actually id and user_name. So your SQL query should be like this;
sql = 'select id, user_name from users_info where id = 3'

Did you check your sql statement? Based on your table your columns are "id", "user_name" and "passwd", but in your sql you are searching for "id" and "name", and "name" isn't a column so that will throw an error. Change your sql to "sql='select id,user_name from users_info where id=3'"

As ruohola already explained in his answer, your exception handler is hiding all the important informations about what really went wrong - FWIW, there's the "Error !" string printed in your screen capture just above the None. The point is: your try/except block is not only useless, it's actually harmful - it prevents some other code up the call stack to even be aware that there was a problem (and eventually solve it), it also prevents you from knowing what went wrong. As a general rule, only catch exception the exact exception that you expect AND can effectively handle at this point in the code - if you can't fix the error at this point, let the exception propagate and let the calling code deal with it. Also, you want to have as few code as possible in your try clause (the only exception being the application's top-level exception handler of course).
This being said, there is indeed a very valid reason for wanting to be warned of exception, which is to make sure you free resources (and eventually rollback a transaction), but then you want 1/ to use a finally clause for resources cleanup (a finally block is always executed, whatever happens) and 2/ for the rollback part, use an except clause but re-raise the exception, ie:
# leave this one out of the try block -
# there's nothing you can do here about a connection error
# so let the calling code deal with it
self.connect()
try:
self.cursor.execute(sql, params)
except Exception as e:
self.connection.rollback()
finally:
# this will ALWAYS be executed (unless `self.connect()` raised
# but then you don't even want to close the connection <g>
self.close()
wrt/ the real cause of your problem, Kurose's answer is certainly the right one.
Also, there are a quite a few other things that are debatable with your "mysql_encapsulation" class (the naming to start with but let ignore this ATM), the main one being to open and close the connection for each query. Opening a database connection has a rather high cost, so you want to keep it opened as long as possible (and eventually reconnect if you get a "2006 mysql has gone away" error).

Related

why do Syntax error (python) doesn't work?

I want to print a message in case the user made a mistake while writing the code but it doesnt work I also tried to add NameError exception, it only works if I raise an exception.Thank you for helping.
`
def cncours(nvcours,num_cours):
try :
sql="Update cours set nomC=%s where num_cours=%s"
result=cursor.fetchone()
cursor.execute(sql,(nvcours,num_cours))
print("Operation Done.")
except TypeError:
print("Plz put the name between quotes")
`
Each DB implementation (MySQL, sqlite,...) may raise their particular exceptions. So instead of catching a general exceptions, you may catch errors depending on the specific DB, then on the particular type (e.g. SyntaxError). I suggest to provoque a syntax error on your SQL statement then see what type is (e.g. errorcode or exception type) then catch it.
For instance, the MySQL connector raises error numbers:
import mysql.connector as cn
try:
#...
except cn.Error as err:
print("Something went wrong: {}".format(err))
if err.errno == errorcode.ER_BAD_TABLE_ERROR: #
Here are some MySQL Error Code Ranges
If you are using MySQLdb:
import MySQLdb
try:
#...
cursor.execute(sql)
res = cursor.fetchone()
# ...
except MySQLdb.Error, e:
print "MySQLdb.Error: {}".format(e.args)
Depending on your schema (column types) and the type from the input variable, you may use:
sql="Update cours set nomC='%s' where num_cours=%s" # Added quotes on the first replacement
Besides what you are asking, I think that the command order is inverted.
sql="Update cours set nomC=%s where num_cours=%s"
cursor.execute(sql,(nvcours,num_cours)) # First
result=cursor.fetchone() # Second
print("Operation Done.")
https://www.tutorialspoint.com/python/python_database_access.htm
# execute SQL query using execute() method.
cursor.execute("SELECT VERSION()")
# Fetch a single row using fetchone() method.
data = cursor.fetchone()

Python - EOF/BOF exception when using GetRows() function (from MDX query)

I wrote this code to retrieve data from a cube:
rs = win32com.client.Dispatch('ADODB.RecordSet')
rs.__init__
conn = win32com.client.Dispatch('ADODB.Connection')
conn.__init__
conn.CommandTimeout=3000
conn.Open(connString)
#Retrieving data
try:
rs.Open(mdxQuery, conn, 1, 3)
except Exception as e:
print("An error occured while trying to retrieve data:")
print(str(e))
sys.exit(1)
try:
t=rs.GetRows()
except Exception as ex:
print(str(ex))
it seems the mdx query is ok, and retrieve some result (I can see it from debug mode)
but when I try to assign the result of GetRows() function to a variable, it fails, with the following message:
ADODB.Field : Either BOF or EOF is True, or the current record has been deleted. Requested operation requires a current record.
It seems to me GetRows() function is not able to handle NULL values. Is there a way to tell that method to skip NULL values or just fill it with blanks, and avoid this error?
Thanks

Python-mysql: when to explicitly rollback a transaction

Suppose, I have a modifying statement:
cursor = conn.cursor()
# some code
affected_rows1 = cursor.execute(update_statement1, params1)
# some code
conn.commit()
cursor.close()
Should I wrap the block of code with a try ... except and explicitly rollback a transaction when an exception is raised, and which MySQLdb exceptions should I catch to rollback? I used to catch any StandardError in this case, but now I have a hesitation that the block of code would even need an explicit rollback at all.
The following example is slightly more difficult, and I understand that it does require an explicit rollback if the first update statement succeeded. Still, which exceptions should I catch in this case:
cursor = conn.cursor()
# some code
affected_rows1 = cursor.execute(update_statement1, params1)
# some code
affected_rows2 = cursor.execute(update_statement2, params2)
#some code
conn.commit()
cursor.close()
This link shows the various types of Errors that you can catch. MySQLdb.Error is the standard base class from which all other MySQL Errors are derived.
I usually use MySQLdb.Error because it lets you focus on errors relating to MySQLdb itself. By contrast StandardError will catch almost all the exceptions (not something you want if you want better debugging capability). Plus the use of MySQLdb.Error allows you to display the exact error message (MySQL error number and all) so that you can debug it faster.
Coming to the first part of the question, in case of database statements it is (usually) necessary to rollback transactions (if they are supported) in case of error.
The methodology that I follow is to wrap each execute statement in a try except clause (catching MySQLdb.Error) and using rollback if there is an an error before printing the error message and exiting.
However, there is a catch. In MySQLdb the changes that you make to DB are not actually written to the database until you explicilty call commit. So, logically, rollback is not necessary.
As an example,
conn = MySQLdb.connection(db=, host=, passwd=, user=)
cur = conn.cursor()
#Say you have a table X with one entry id = 1 and total = 50
cur.execute("update X set total = 70 where id = 1")
#Actual DB has not yet changed
cur.execute("update X set total = 80 where id = 1")
#Actual DB has still not changed
If you exit the program without commiting, the value in DB will still be 50 because you never called commit().
This is how you would ideally do it:
conn = MySQLdb.connection(db=, host=, passwd=, user=)
cur = conn.cursor()
#Say you have a table X with one entry id = 1 and total = 50
try:
cur.execute("update X set total = 70 where id = 1")
except MySQLdb.Error,e:
print e[0], e[1]
conn.rollback()
cur.close()
conn.close()
#print lengthy error description!!
sys.exit(2)
#Note: Value in table is still 50
#If you do conn.commit() here, value becomes 70 in table too!!
try:
cur.execute("update X set total = 80 where id = 1")
except MySQLdb.Error,e:
print e[0], e[1]
conn.rollback()
cur.close()
conn.close()
#print lengthy error description!!
sys.exit(2)
#Value in DB will be
#a) 50 if you didn't commit anywhere
#b) 70 if you committed after first execute statement
conn.commit()
#Now value in DB is 80!!
cur.close()
conn.close()
IMHO, you should rollback transactions if you continue to use the same connection. Else everything before the error will get commit when you finish the transactions.
For the exception to catch, I always use MySQLdb.Error but I'm not sure that's correct.
Its advised to wrap execute() in a sub. This is how i do it.
def executeSQL(self, stmt):
cursor = self.dbHand.cursor()
if not stmt.endswith(";"):
stmt += ';'
try:
cursor.execute(stmt)
except MySQLdb.Error, e:
self.logger.error("Caught MYSQL exception :%s: while executing stmt :%s:.\n"%(e,stmt))
return False

Why do I get SQLAlchemy nested rollback error?

I got an error as follows in my code of python (which collects twitter statuses and store in database).
sqlalchemy.exc.InvalidRequestError: This Session's transaction has been rolled back by a nested rollback() call. To begin a new transaction, issue Session.rollback() first.
I want to know what is the problem, why does it occur, and how can I solve it.
I have no idea about nested rollback. Is there any simple example which occurs nested rollback?
The problem was solved.
The point, in this case, is that rollback is not executed until we call rollback explicitly, so when we include commit(), we should write it in a try statement, and write rollback() in the exception statement (in most case) as written in https://docs.sqlalchemy.org/en/13/faq/sessions.html#this-session-s-transaction-has-been-rolled-back-due-to-a-previous-exception-during-flush-or-similar
And, here is the correct code example. I quoted this from the link above.
try:
<use session>
session.commit()
except:
session.rollback()
raise
finally:
session.close() # optional, depends on use case
As identified by #fbessho above, this is indeed the correct pattern:
try:
<use session>
session.commit()
except:
session.rollback()
However, there are some subtleties that can derail the error handling.
In this example (an imaginary unique constraint violation), the rollback does not occur:
class Thing1(Base):
id = Column(BigInteger, primary_key=True)
class Thing2(Base):
id = Column(BigInteger, primary_key=True)
def do_something(s: session, thing_1: Thing1, duplicate_id):
# imagine this violates a unique constraint on Thing2
thing_2 = Thing2(id=duplicate_id)
s.add(thing_2)
try:
# the exception will occur when the commit statement is executed
s.commit()
except Exception as ex:
# this will log details of the exception
logger.error(f"{ex.__class__.__name__}: {ex}")
# referencing thing_1.id will raise a second exception
logger.error(f"Commit failed. Thing1 id was {thing_1.id}.")
s.rollback()
This second Exception occurs even though thing_1 has nothing to do with the failed insert. Merely referencing thing_1 raises a second Exception which prevents the rollback from being executed.
Solution 1
This requires a little more overhead, but will always work.
def do_something_1(s: session, thing_1: Thing1, duplicate_id):
# create a reference that does not rely on the data object
id_for_thing = thing_1.id
# imagine this violates a unique constraint on Thing2
thing_2 = Thing2(id=duplicate_id)
s.add(thing_2)
try:
# the exception will occur when the commit statement is executed
s.commit()
except Exception as ex:
logger.error(f"{ex.__class__.__name__}: {ex}")
# no direct reference to thing_1
logger.error(f"Commit failed. Thing1 id was {id_for_thing}.")
s.rollback()
Solution 2
This will work as long as thing_1 is not affected by the rollback.
def do_something_2(s: session, thing_1: Thing1, duplicate_id):
# imagine this violates a unique constraint on Thing2
thing_2 = Thing2(id=duplicate_id)
s.add(thing_2)
try:
# the exception will occur when the commit statement is executed
s.commit()
except Exception as ex:
logger.error(f"{ex.__class__.__name__}: {ex}")
s.rollback()
# thing_1.id can be referenced after rollback
logger.error(f"Commit failed. Thing1 id was {thing_1.id}.")

Commiting data from Tweepy to a sqlite3 database, no matter what I do, db remains empty

Code:
import time
import tweepy
import sqlite3
class Listener(tweepy.StreamListener):
conn = sqlite3.connect('/home/daniel/Desktop/activeSites/djeep/djeep.db')
def on_status(self, status):
try:
c = self.conn.cursor()
c.execute("""insert into feed_post values (%r,'%s','%s',%d)""") % (status.id, status.text, status.author.screen_name, status.created_at)
self.conn.commit()
except:
pass
def on_error(self, status_code):
print 'An error has occured! Status code = %s' % status_code
return True # keep stream alive
def on_timeout(self):
print 'timeout...'
def main():
auth = tweepy.OAuthHandler('C_KEY', 'C_SECRET')
auth.set_access_token('ACCESS_TOKEN', 'ACCESS_SECRET')
stream = tweepy.Stream(auth=auth, listener=Listener())
stream.filter(track=('baseball',))
if __name__=="__main__":
try:
main()
except KeyboardInterrupt:
print "See ya!"
I've gone back and added one line of the database related code at a time to try and find out what breaks it, and it seems to be the addition of the c.execute() line. I just can't figure out what I'm missing!
The path to the database should be an argument to your script, not hardcoded. It should be supplied to your class each time the class is instantiated, NOT when your class is created. However it's not apparent that that is the cause of your problem, not yet exactly what the problem is:
Your title indicates that you can't get anything written to your database, but the question body implies that something "breaks" when you add in c.execute -- which is correct? What are the symptoms when it "breaks"?
Your try\yadda\except\pass is silently ignoring all possible exceptions -- don't do that! Remove the try\except\pass leaving only the yadda, answer the above questions, and let us know the outcome.
UPDATE: Your c.execute() statement is a shocker. Making it legible without scrolling, it's equivalent to this:
(
c.execute("""insert into feed_post values (%r,'%s','%s',%d)""")
%
(status.id, status.text, status.author.screen_name, status.created_at)
)
In other words, you have a right parenthesis grossly misplaced. The result is syntactically valid, but is sure to cause an exception at run time.
Worse: you are setting yourself up for an SQL injection attack. Use parameters instead of string formatting:
sql = "insert into feed_post values (?,?,?,?)"
params = (status.id, status.text, status.author.screen_name, status.created_at)
c.execute(sql, params)
A bonus from this approach is that it should run much faster, as the engine will not need to parse (or have its cache swamped by) a typically-different SQL statement for each row written.
Try taking the self references out of the class, or use an __init__ function to initialize self.conn
def __init__(self):
self.conn = sqlite3.connect('/home/daniel/Desktop/activeSites/djeep/djeep.db')
def on_status(self, status):
try:
c = self.conn.cursor()
c.execute(SQL...)
self.conn.commit()
except:
pass
I agree with machin though, pass your connection and cursor objects as parameters when you initialize the object.

Categories

Resources