From richmoore44 at gmail.com Wed Feb 1 23:49:09 2006 From: richmoore44 at gmail.com (Richard Moore) Date: Wed, 1 Feb 2006 22:49:09 +0000 Subject: [DB-SIG] pydbfactory v2 Message-ID: <5491a5150602011449s55a85a79m54a0581c6bd16cf3@mail.gmail.com> Hi All, Well, several people downloaded the DB factory code I posted last weekend, but no one has given me any feedback on it so far. I've now written an additional driver for cx_Oracle as I said. You can find the code at: http://xmelegance.org/downloads/pydbfactory-0.2.zip Any thoughts? Rich. From python_eager at yahoo.com Wed Feb 1 07:57:41 2006 From: python_eager at yahoo.com (python eager) Date: Tue, 31 Jan 2006 22:57:41 -0800 (PST) Subject: [DB-SIG] delete the records query Message-ID: <20060201065741.26544.qmail@web36413.mail.mud.yahoo.com> Hi, This my code snippet. I am deleting records. But the sql statment working fine. but it will not delete. i have two files. one is db_connection, and other one is PerDetailsDAO. i am creating object in PerDetailsDAO for db_connection.py Thereafter executing the sql statement. But the particular record will not deleted. What is the error? Please rectify the problem Thank you File Name : db_connection.py import cx_Oracle class db_connection: def getConnection(self): dbconnection = cx_Oracle.connect("username", "password", "hoststring") cursor = dbconnection.cursor() cursor.arraysize = 50 return cursor File Name : PerDetailsDAO.py class PerDetailsDAO: def delete(self,pid): con = db_connection() cursor = con.getConnection() sql = "DELETE FROM PERSONALDETAILS WHERE PID =100" cursor.execute(sql) regards Python Eager --------------------------------- Do you Yahoo!? With a free 1 GB, there's more in store with Yahoo! Mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20060131/8465c123/attachment.html From ccurvey at gmail.com Thu Feb 2 13:58:38 2006 From: ccurvey at gmail.com (Chris Curvey) Date: Thu, 2 Feb 2006 07:58:38 -0500 Subject: [DB-SIG] delete the records query In-Reply-To: <20060201065741.26544.qmail@web36413.mail.mud.yahoo.com> References: <20060201065741.26544.qmail@web36413.mail.mud.yahoo.com> Message-ID: <25ef693e0602020458s8ea8459scf2bab6d50ee1d55@mail.gmail.com> Most likely, it's that you are not committing the transaction. On 2/1/06, python eager wrote: > > Hi, This my code snippet. > I am deleting records. But the sql statment working fine. but it will not > delete. i have two files. one is db_connection, and other one is > PerDetailsDAO. > > i am creating object in PerDetailsDAO for db_connection.py > Thereafter executing the sql statement. > But the particular record will not deleted. > What is the error? > Please rectify the problem > Thank you > > > *File Name : db_connection.py* > ** > import cx_Oracle > class db_connection: > def getConnection(self): > dbconnection = cx_Oracle.connect("username", "password", > "hoststring") > cursor = dbconnection.cursor() > cursor.arraysize = 50 > return cursor > > *File Name : PerDetailsDAO.py* > ** > class PerDetailsDAO: > def delete(self,pid): > con = db_connection() > cursor = con.getConnection() > sql = "DELETE FROM PERSONALDETAILS WHERE PID =100" > cursor.execute(sql) > regards > Python Eager > > > ------------------------------ > Do you Yahoo!? > With a free 1 GB, there's more in store with Yahoo! Mail. > > > _______________________________________________ > DB-SIG maillist - DB-SIG at python.org > http://mail.python.org/mailman/listinfo/db-sig > > > -- Nervous passengers are advised to wear a blindfold. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20060202/af33615a/attachment.html From python_eager at yahoo.com Fri Feb 3 07:53:51 2006 From: python_eager at yahoo.com (python eager) Date: Thu, 2 Feb 2006 22:53:51 -0800 (PST) Subject: [DB-SIG] How to use Prepared Statment? Message-ID: <20060203065351.59472.qmail@web36410.mail.mud.yahoo.com> Hi this my code snippet. This code will not execute. And also this code raise error. DatabaseError: ORA-01036: illegal variable name/number What is the problem. Please give me a solution. Is there any problem is sql statment please give the correct statment, i will apply that statment. Code Snippet : def view_one(self,pid): sql_pStmt = "SELECT FIRSTNAME,LASTNAME FROM PERSONALDETAILS WHERE PID = ?" cursor.execute(sql_pStmt,pid) Thank you regards Python Eager --------------------------------- Relax. Yahoo! Mail virus scanning helps detect nasty viruses! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20060202/6381c130/attachment.htm From andy47 at halfcooked.com Fri Feb 3 09:28:52 2006 From: andy47 at halfcooked.com (Andy Todd) Date: Fri, 03 Feb 2006 19:28:52 +1100 Subject: [DB-SIG] How to use Prepared Statment? In-Reply-To: <20060203065351.59472.qmail@web36410.mail.mud.yahoo.com> References: <20060203065351.59472.qmail@web36410.mail.mud.yahoo.com> Message-ID: <43E31444.9050309@halfcooked.com> python eager wrote: > Hi this my code snippet. This code will not execute. And also this code > raise error. > > DatabaseError: ORA-01036: illegal variable name/number > > What is the problem. Please give me a solution. Is there any problem is > sql statment please give the correct statment, i will apply that statment. > > > _Code Snippet :_ > __ > *def view_one(self,pid): > *sql_pStmt = "SELECT FIRSTNAME,LASTNAME FROM PERSONALDETAILS > WHERE PID = ?" > cursor.execute(sql_pStmt,pid) > > Thank you > > regards > Python Eager > From the cx_Oracle documentation (section 3) [1]; """ execute(statement, [parameters], **keywordParameters) Execute a statement against the database. Parameters may be passed as a dictionary or sequence or as keyword arguments. If the arguments are a dictionary, the values will be bound by name and if the arguments are a sequence the values will be bound by position." """ From the DB-API specification [2]; """ paramstyle String constant stating the type of parameter marker formatting expected by the interface. Possible values are [2]: 'qmark' Question mark style, e.g. '...WHERE name=?' 'numeric' Numeric, positional style, e.g. '...WHERE name=:1' 'named' Named style, e.g. '...WHERE name=:name' 'format' ANSI C printf format codes, e.g. '...WHERE name=%s' 'pyformat' Python extended format codes, e.g. '...WHERE name=%(name)s' """ cx_Oracle uses the 'named' parameter style, your code uses the qmark style. To find out which style is applicable check the paramstyle attribute of your connection object. e.g.; >>> import cx_Oracle >>> myConnection = cx_Oracle.connect('andy47/andy47 at andy47') >>> myConnection.paramstyle 'named' [1] http://starship.python.net/crew/atuining/cx_Oracle/html/cursorobj.html [2] http://www.python.org/peps/pep-0249.html Regards, Andy -- -------------------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com/ From python_eager at yahoo.com Fri Feb 3 11:10:03 2006 From: python_eager at yahoo.com (python eager) Date: Fri, 3 Feb 2006 02:10:03 -0800 (PST) Subject: [DB-SIG] How to use Prepared Statment? Facing Error In-Reply-To: <43E31444.9050309@halfcooked.com> Message-ID: <20060203101003.63638.qmail@web36411.mail.mud.yahoo.com> hi, i am using the same method what you suggest. While running the program i am getting the following error AttributeError: db_connection instance has no attribute 'paramstyle' Please rectify the error thank you Python Eager Andy Todd wrote: python eager wrote: > Hi this my code snippet. This code will not execute. And also this code > raise error. > > DatabaseError: ORA-01036: illegal variable name/number > > What is the problem. Please give me a solution. Is there any problem is > sql statment please give the correct statment, i will apply that statment. > > > _Code Snippet :_ > __ > *def view_one(self,pid): > *sql_pStmt = "SELECT FIRSTNAME,LASTNAME FROM PERSONALDETAILS > WHERE PID = ?" > cursor.execute(sql_pStmt,pid) > > Thank you > > regards > Python Eager > >From the cx_Oracle documentation (section 3) [1]; """ execute(statement, [parameters], **keywordParameters) Execute a statement against the database. Parameters may be passed as a dictionary or sequence or as keyword arguments. If the arguments are a dictionary, the values will be bound by name and if the arguments are a sequence the values will be bound by position." """ >From the DB-API specification [2]; """ paramstyle String constant stating the type of parameter marker formatting expected by the interface. Possible values are [2]: 'qmark' Question mark style, e.g. '...WHERE name=?' 'numeric' Numeric, positional style, e.g. '...WHERE name=:1' 'named' Named style, e.g. '...WHERE name=:name' 'format' ANSI C printf format codes, e.g. '...WHERE name=%s' 'pyformat' Python extended format codes, e.g. '...WHERE name=%(name)s' """ cx_Oracle uses the 'named' parameter style, your code uses the qmark style. To find out which style is applicable check the paramstyle attribute of your connection object. e.g.; >>> import cx_Oracle >>> myConnection = cx_Oracle.connect('andy47/andy47 at andy47') >>> myConnection.paramstyle 'named' [1] http://starship.python.net/crew/atuining/cx_Oracle/html/cursorobj.html [2] http://www.python.org/peps/pep-0249.html Regards, Andy -- -------------------------------------------------------------------------------- >From the desk of Andrew J Todd esq - http://www.halfcooked.com/ --------------------------------- Yahoo! Mail - Helps protect you from nasty viruses. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20060203/318cd7a5/attachment.html From andy47 at halfcooked.com Fri Feb 3 11:26:00 2006 From: andy47 at halfcooked.com (Andy Todd) Date: Fri, 03 Feb 2006 21:26:00 +1100 Subject: [DB-SIG] How to use Prepared Statment? Facing Error In-Reply-To: <20060203101003.63638.qmail@web36411.mail.mud.yahoo.com> References: <20060203101003.63638.qmail@web36411.mail.mud.yahoo.com> Message-ID: <43E32FB8.6040704@halfcooked.com> python eager wrote: > hi, i am using the same method what you suggest. While running the > program i am getting the following error > > AttributeError: db_connection instance has no attribute 'paramstyle' > > Please rectify the error > > thank you > Python Eager > > */Andy Todd /* wrote: > > python eager wrote: > > Hi this my code snippet. This code will not execute. And also > this code > > raise error. > > > > DatabaseError: ORA-01036: illegal variable name/number > > > > What is the problem. Please give me a solution. Is there any > problem is > > sql statment please give the correct statment, i will apply that > statment. > > > > > > _Code Snippet :_ > > __ > > *def view_one(self,pid): > > *sql_pStmt = "SELECT FIRSTNAME,LASTNAME FROM PERSONALDETAILS > > WHERE PID = ?" > > cursor.execute(sql_pStmt,pid) > > > > Thank you > > > > regards > > Python Eager > > > > From the cx_Oracle documentation (section 3) [1]; > > """ > execute(statement, [parameters], **keywordParameters) > Execute a statement against the database. Parameters may be passed as > a dictionary or sequence or as keyword arguments. If the arguments > are a > dictionary, the values will be bound by name and if the arguments are a > sequence the values will be bound by position." > """ > > From the DB-API specification [2]; > > """ > paramstyle > > String constant stating the type of parameter marker > formatting expected by the interface. Possible values are > [2]: > > 'qmark' Question mark style, > e.g. '...WHERE name=?' > 'numeric' Numeric, positional style, > e.g. '...WHERE name=:1' > 'named' Named style, > e.g. '...WHERE name=:name' > 'format' ANSI C printf format codes, > e.g. '...WHERE name=%s' > 'pyformat' Python extended format codes, > e.g. '...WHERE name=%(name)s' > """ > > cx_Oracle uses the 'named' parameter style, your code uses the qmark > style. To find out which style is applicable check the paramstyle > attribute of your connection object. e.g.; > > >>> import cx_Oracle > >>> myConnection = cx_Oracle.connect('andy47/andy47 at andy47') > >>> myConnection.paramstyle > 'named' > > [1] > http://starship.python.net/crew/atuining/cx_Oracle/html/cursorobj.html > [2] http://www.python.org/peps/pep-0249.html > > Regards, > Andy > -- > -------------------------------------------------------------------------------- > From the desk of Andrew J Todd esq - http://www.halfcooked.com/ > That's my mistake for not reading the documentation and just typing some sample code into my email rather than actually firing up a Python interpreter. Let that be a lesson to us all. >>> import cx_Oracle >>> cx_Oracle.paramstyle 'named' Regards, Andy -- -------------------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com/ From python_eager at yahoo.com Wed Feb 8 05:08:20 2006 From: python_eager at yahoo.com (python eager) Date: Tue, 7 Feb 2006 20:08:20 -0800 (PST) Subject: [DB-SIG] reg cursor.fetchall() Message-ID: <20060208040820.78281.qmail@web36404.mail.mud.yahoo.com> Hi , This is my statment which will work fine. but the statment line is long. How to split up these lines . Code Snippet : for PID,FIRSTNAME,MIDDLENAME,LASTNAME, MARITALSTATUS,EMPLOYEESTATUS,NOD,SALARY, POI,RADDRESS,OADDRESS,MNO,LNO,DOBD,DOBM, DOBY,DOID,DOIM,DOIY,DOED,DOEM,DOEY in cursor.fetchall(): Please help me regards Python Eager --------------------------------- Brings words and photos together (easily) with PhotoMail - it's free and works with Yahoo! Mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20060207/ad03cd08/attachment.html From andy47 at halfcooked.com Wed Feb 8 11:44:20 2006 From: andy47 at halfcooked.com (Andy Todd) Date: Wed, 08 Feb 2006 21:44:20 +1100 Subject: [DB-SIG] reg cursor.fetchall() In-Reply-To: <20060208040820.78281.qmail@web36404.mail.mud.yahoo.com> References: <20060208040820.78281.qmail@web36404.mail.mud.yahoo.com> Message-ID: <43E9CB84.5050204@halfcooked.com> python eager wrote: > Hi , This is my statment which will work fine. but the statment line is > long. How to split up these lines . > > *Code Snippet :* > > for PID,FIRSTNAME,MIDDLENAME,LASTNAME, > MARITALSTATUS,EMPLOYEESTATUS,NOD,SALARY, > POI,RADDRESS,OADDRESS,MNO,LNO,DOBD,DOBM, > DOBY,DOID,DOIM,DOIY,DOED,DOEM,DOEY in cursor.fetchall(): > > Please help me > > regards > Python Eager > > > _______________________________________________ > DB-SIG maillist - DB-SIG at python.org > http://mail.python.org/mailman/listinfo/db-sig The usual pattern is something like (untested, please ignore syntax errors); >>> myCursor.execute("SELECT x,y,z FROM tablea") >>> for row in cursor.fetchall(): ... print "Column x:", row[0] ... print "y * z = %d" % (row[1] * row[2]) e.g. return each row of your results into a tuple and then reference the individual elements by index. Sadly cx_Oracle doesn't offer different cursor classes like, for instance, MySQLdb; http://dustman.net/andy/python/MySQLdb_obsolete/doc/MySQLdb-4.html#usage So you can't refer to cursor results as dictionaries or other sequence types. Regards, Andy -- -------------------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com/ From carsten at uniqsys.com Wed Feb 8 15:07:32 2006 From: carsten at uniqsys.com (Carsten Haese) Date: Wed, 08 Feb 2006 09:07:32 -0500 Subject: [DB-SIG] reg cursor.fetchall() In-Reply-To: <20060208040820.78281.qmail@web36404.mail.mud.yahoo.com> References: <20060208040820.78281.qmail@web36404.mail.mud.yahoo.com> Message-ID: <1139407651.28143.29.camel@dot.uniqsys.com> On Tue, 2006-02-07 at 23:08, python eager wrote: > Hi , This is my statment which will work fine. but the statment line > is long. How to split up these lines . > > Code Snippet : > > for PID,FIRSTNAME,MIDDLENAME,LASTNAME, > MARITALSTATUS,EMPLOYEESTATUS,NOD,SALARY, > POI,RADDRESS,OADDRESS,MNO,LNO,DOBD,DOBM, > DOBY,DOID,DOIM,DOIY,DOED,DOEM,DOEY in cursor.fetchall(): You could split this up if you place parentheses around the tuple, but it's probably not a good idea to pollute your namespace with a million little column names like this. Also, if the set of columns in your query changes, you'd have to change that for line as well. An alternative is to define a class whose instances contain the column values as attributes. Example: class RowObject(object): def __init__(self, data, description): self.__dict__.update(dict(zip([col[0] for col in description], data))) for rowdata in cursor.fetchall(): row = RowObject(rowdata, cursor.description) # now you can do stuff with row.PID, row.FIRSTNAME, or however the columns # in the query are named. By the way, you might not have to fetch all rows and then loop over the list that gets returned. Most DB-API modules allow you to iterate over the cursor: for rowdata in cursor: # do stuff For large result sets this is more efficient because you only process one row at a time instead of sucking the entire result set into one huge list. Hope this helps, Carsten. From python_eager at yahoo.com Fri Feb 10 10:07:00 2006 From: python_eager at yahoo.com (python eager) Date: Fri, 10 Feb 2006 01:07:00 -0800 (PST) Subject: [DB-SIG] query - prepared statment Message-ID: <20060210090700.17076.qmail@web36407.mail.mud.yahoo.com> Hi All, How to use prepared statment. Can u give one example for insert, delete and update statments. please. Thank you regards Python Eager --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20060210/0bf0b327/attachment.htm From carsten at uniqsys.com Fri Feb 10 14:42:52 2006 From: carsten at uniqsys.com (Carsten Haese) Date: Fri, 10 Feb 2006 08:42:52 -0500 Subject: [DB-SIG] query - prepared statment In-Reply-To: <20060210090700.17076.qmail@web36407.mail.mud.yahoo.com> References: <20060210090700.17076.qmail@web36407.mail.mud.yahoo.com> Message-ID: <1139578971.2349.34.camel@dot.uniqsys.com> On Fri, 2006-02-10 at 04:07, python eager wrote: > Hi All, > > How to use prepared statment. Can u give one example for insert, > delete and update statments. please. The DB-API standard does not define a separate method for preparing a statement. Preparing the statement is part of the cursor.execute() and executemany() methods. execute() prepares the statement and executes it with the given parameters. executemany() should prepare the statement once and execute it many times over, once for each set of parameters. For DB-API implementations that implement statement caching (informixdb and cx_Oracle, for example), the first execute call takes the place of preparing a statement. If you subsequently execute the same query string on the same cursor with different parameters, the same prepared statement is reused. Apparently cx_Oracle implements a non-standard prepare() method that prepares a query string for later execution by either passing the same string or None to execute(). I'll give you an (untested because I don't use Oracle) example for delete. I'm sure you can figure out the other cases yourself. import cx_Oracle conn = cx_Oracle.connect(...) cur = conn.cursor() cur.prepare("delete from sometable where someID = ?") for id in somelist: cur.execute(None, (id,) ) Note that in a standard DB-API implementation, you'd simply write import somedb conn = somedb.connect(...) cur = conn.cursor() for id in somelist: cur.execute("delete from sometable where someID = ?", (id,) ) which is just as efficient if the module implements statement caching. Hope this helps, Carsten. From farcepest at gmail.com Fri Feb 10 22:52:24 2006 From: farcepest at gmail.com (Andy Dustman) Date: Fri, 10 Feb 2006 16:52:24 -0500 Subject: [DB-SIG] reg cursor.fetchall() In-Reply-To: <43E9CB84.5050204@halfcooked.com> References: <20060208040820.78281.qmail@web36404.mail.mud.yahoo.com> <43E9CB84.5050204@halfcooked.com> Message-ID: <9826f3800602101352x1f0ed759g3376d72fa0236a27@mail.gmail.com> On 2/8/06, Andy Todd wrote: > Sadly cx_Oracle doesn't offer different cursor classes like, for > instance, MySQLdb; > > http://dustman.net/andy/python/MySQLdb_obsolete/doc/MySQLdb-4.html#usage > > So you can't refer to cursor results as dictionaries or other sequence > types. You can actually take any DB-API database result row and turn it into a dictionary: >>> import MySQLdb >>> db=MySQLdb.connect(db="mysql",read_default_file="~/.my.cnf") >>> c=db.cursor() >>> c.execute("select * from user") 6L >>> for row in c.fetchall(): ... d = dict( [ (c.description[i][0], j) for i,j in enumerate(row) ] ) ... print d ... {'Drop_priv': 'Y', 'Execute_priv': 'Y', 'Create_routine_priv': 'Y', 'Repl_client_priv': 'Y', 'Create_user_priv': 'Y', 'Create_priv': 'Y', 'References_priv': 'Y', 'max_user_connections': 0L, 'Shutdown_priv': 'Y', 'Grant_priv': 'Y', 'max_updates': 0L, 'max_connections': 0L, 'Show_db_priv': 'Y', 'Reload_priv': 'Y', 'Super_priv': 'Y', 'Host': 'localhost', 'User': 'root', 'Alter_priv': 'Y', 'ssl_cipher': array('c'), 'Password': 'xxx', 'Delete_priv': 'Y', 'Repl_slave_priv': 'Y', 'Insert_priv': 'Y', 'x509_subject': array('c'), 'ssl_type': '', 'Index_priv': 'Y', 'Create_tmp_table_priv': 'Y', 'x509_issuer': array('c'), 'Create_view_priv': 'Y', 'Select_priv': 'Y', 'Show_view_priv': 'Y', 'Update_priv': 'Y', 'Lock_tables_priv': 'Y', 'Process_priv': 'Y', 'Alter_routine_priv': 'Y', 'File_priv': 'Y', 'max_questions': 0L} ... Or make a helper function to do this. (Example left as an exercise for the reader.) -- The Pythonic Principle: Python works the way it does because if it didn't, it wouldn't be Python. From mal at egenix.com Fri Feb 10 23:15:36 2006 From: mal at egenix.com (M.-A. Lemburg) Date: Fri, 10 Feb 2006 23:15:36 +0100 Subject: [DB-SIG] query - prepared statment In-Reply-To: <1139578971.2349.34.camel@dot.uniqsys.com> References: <20060210090700.17076.qmail@web36407.mail.mud.yahoo.com> <1139578971.2349.34.camel@dot.uniqsys.com> Message-ID: <43ED1088.1050800@egenix.com> Carsten Haese wrote: > On Fri, 2006-02-10 at 04:07, python eager wrote: >> Hi All, >> >> How to use prepared statment. Can u give one example for insert, >> delete and update statments. please. > > The DB-API standard does not define a separate method for preparing a > statement. Preparing the statement is part of the cursor.execute() and > executemany() methods. execute() prepares the statement and executes it > with the given parameters. executemany() should prepare the statement > once and execute it many times over, once for each set of parameters. > > For DB-API implementations that implement statement caching (informixdb > and cx_Oracle, for example), the first execute call takes the place of > preparing a statement. If you subsequently execute the same query string > on the same cursor with different parameters, the same prepared > statement is reused. > > Apparently cx_Oracle implements a non-standard prepare() method that > prepares a query string for later execution by either passing the same > string or None to execute(). Perhaps we should something like this to the list of standard DB-API extensions ?! This is what we have in mxODBC 2.1: cursor.prepare(operation) Prepare a database operation (query or command) statement for later execution and set cursor.command. To execute a prepared statement, pass cursor.statement to one of the .executeXXX() methods. Return values are not defined. cursor.command Provides access to the last prepared or executed SQL command available through the cursor. If no such command is available, None is returned. Looks very similar to what cx_Oracle implements. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 10 2006) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From davidrushby at yahoo.com Sat Feb 11 01:38:09 2006 From: davidrushby at yahoo.com (David Rushby) Date: Fri, 10 Feb 2006 16:38:09 -0800 (PST) Subject: [DB-SIG] query - prepared statment In-Reply-To: <43ED1088.1050800@egenix.com> Message-ID: <20060211003809.57036.qmail@web30007.mail.mud.yahoo.com> --- "M.-A. Lemburg" wrote: > Perhaps we should something like this to the list of standard > DB-API extensions ?! > > This is what we have in mxODBC 2.1: > > cursor.prepare(operation) > > Prepare a database operation (query or command) statement for > later execution and set cursor.command. To execute a prepared > statement, pass cursor.statement to one of the .executeXXX() > methods. Return values are not defined. > > cursor.command > Provides access to the last prepared or executed SQL command > available through the cursor. If no such command is available, > None is returned. > > Looks very similar to what cx_Oracle implements. kinterbasdb implements similar functionality this way: --- cursor.prep(sql_string) Prepare a SQL statement for later execution. Return a PreparedStatement object that can later be passed as the first parameter to cursor.executeXXX() instead of a SQL string. --- I'd definitely suggest the method name "prepare" as the standard instead of "prep"--I chose "prep" specifically so it wouldn't clash with the anticipated addition of "prepare" to the standard. However, I would find the cx_Oracle-style interface that Carsten described too constraining. Why not let the user create and manipulate as many PreparedStatement objects as desired, and let PreparedStatements expose whatever properties and methods are appropriate for the database engine, instead of confining the whole prepared statement concept to "I'm about to execute this statement a bunch of times, so don't re-prepare it every time". kinterbasdb.PreparedStatement objects expose properties that contain: - the SQL string on which the PreparedStatement is based - a code indicating the statement type (insert, update, delete, select, execute procedure, etc.) - the plan that the server will use to execute the statement - the number of input parameters - the number of output parameters This information could be crucial to client programs such as database administrative GUIs, where the Python programmer using the database module knows nothing about the SQL statements the user will submit, but needs to examine them programmatically. How would the cx_Oracle-style interface even expose this functionality? cx_Oracle currently exposes a cursor.statement property which contains the SQL string that was most recently "prepared with prepare() or executed with execute()". But the SQL string on which a prepared statement is based is only one of several potentially useful properties, so that interface is not rich enough to be blessed as standard. Also, isn't it advantageous to allow the client programmer to create and manipulate any number of prepared statements, rather than just "the most recent one", as the cx_Oracle-style interface does? Any sophisticated database module will cache and reuse multiple prepared statements internally, so why constrain the public interface to expose just a single prepared statement at a time? I'm in favor of standardizing statement preparation, but not with an interface that precludes all advantages of using prepared statements except those related to efficiency. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From carsten at uniqsys.com Sat Feb 11 03:25:43 2006 From: carsten at uniqsys.com (Carsten Haese) Date: Fri, 10 Feb 2006 21:25:43 -0500 Subject: [DB-SIG] query - prepared statment In-Reply-To: <43ED1088.1050800@egenix.com> References: <20060210090700.17076.qmail@web36407.mail.mud.yahoo.com> <1139578971.2349.34.camel@dot.uniqsys.com> <43ED1088.1050800@egenix.com> Message-ID: <20060211020616.M35703@uniqsys.com> On Fri, 10 Feb 2006 23:15:36 +0100, M.-A. Lemburg wrote > Carsten Haese wrote: > > Apparently cx_Oracle implements a non-standard prepare() method that > > prepares a query string for later execution by either passing the same > > string or None to execute(). > > Perhaps we should something like this to the list of standard > DB-API extensions ?! > > This is what we have in mxODBC 2.1: > > cursor.prepare(operation) > > Prepare a database operation (query or command) statement for > later execution and set cursor.command. To execute a prepared > statement, pass cursor.statement to one of the .executeXXX() > methods. Return values are not defined. > > cursor.command > > Provides access to the last prepared or executed SQL command > available through the cursor. If no such command is available, > None is returned. > > Looks very similar to what cx_Oracle implements. This is easy to implement in InformixDB, so I'll vote +1 to this becoming a standardized optional extension ;) Am I assuming correctly that cursor.command and cursor.statement are two different proposed names for the same thing? I'm +1 for cursor.statement and +0 for cursor.command. -Carsten From carsten at uniqsys.com Sat Feb 11 03:48:41 2006 From: carsten at uniqsys.com (Carsten Haese) Date: Fri, 10 Feb 2006 21:48:41 -0500 Subject: [DB-SIG] query - prepared statment In-Reply-To: <20060211003809.57036.qmail@web30007.mail.mud.yahoo.com> References: <43ED1088.1050800@egenix.com> <20060211003809.57036.qmail@web30007.mail.mud.yahoo.com> Message-ID: <20060211022816.M53962@uniqsys.com> On Fri, 10 Feb 2006 16:38:09 -0800 (PST), David Rushby wrote > --- "M.-A. Lemburg" wrote: > > Perhaps we should something like this to the list of standard > > DB-API extensions ?! > > > > This is what we have in mxODBC 2.1: > > > > cursor.prepare(operation) > > > > Prepare a database operation (query or command) statement for > > later execution and set cursor.command. To execute a prepared > > statement, pass cursor.statement to one of the .executeXXX() > > methods. Return values are not defined. > > > > cursor.command > > Provides access to the last prepared or executed SQL command > > available through the cursor. If no such command is available, > > None is returned. > > > > Looks very similar to what cx_Oracle implements. > > kinterbasdb implements similar functionality this way: > --- > cursor.prep(sql_string) > Prepare a SQL statement for later execution. Return a > PreparedStatement object that can later be passed as the first > parameter to cursor.executeXXX() instead of a SQL string. > --- > > I'd definitely suggest the method name "prepare" as the standard > instead of "prep"--I chose "prep" specifically so it wouldn't clash > with the anticipated addition of "prepare" to the standard. > > However, I would find the cx_Oracle-style interface that Carsten > described too constraining. Why not let the user create and manipulate > as many PreparedStatement objects as desired, and let > PreparedStatements expose whatever properties and methods are > appropriate for the database engine, instead of confining the whole > prepared statement concept to "I'm about to execute this statement a > bunch of times, so don't re-prepare it every time". > > kinterbasdb.PreparedStatement objects expose properties that contain: > - the SQL string on which the PreparedStatement is based > - a code indicating the statement type (insert, update, delete, > select, execute procedure, etc.) > - the plan that the server will use to execute the statement > - the number of input parameters > - the number of output parameters > > This information could be crucial to client programs such as database > administrative GUIs, where the Python programmer using the database > module knows nothing about the SQL statements the user will submit, but > needs to examine them programmatically. > > How would the cx_Oracle-style interface even expose this functionality? > cx_Oracle currently exposes a cursor.statement property which contains > the SQL string that was most recently "prepared with prepare() or > executed with execute()". But the SQL string on which a prepared > statement is based is only one of several potentially useful > properties, so that interface is not rich enough to be blessed as > standard. cursor.description already gives the programmer information about the output parameters. Input parameters and the query plan may be hard to standardize in a meaningful way, but they could be exposed as additional attributes on the cursor without having to resort to a PreparedStatement object. The cursor is the basic DB-API unit that provides the facility for executing statements, and it is in line with the existing standard to expose properties of the most recently executed statements as cursor attributes (description and lastrowid, for example). I wouldn't mind coming up with a list of optional cursor attributes that expose deeper diagnostics for the most recently executed/prepared command. My suggestions would be: statement_type, input_description, and query_plan. The semantics of query_plan and statement_type will probably have to be implementation dependent. I would suggest that a module that implements statement_type should also define constants for basic statement types that a statement_type can be compared to, similar to how type constants work already. I'm -1 on introducing a whole new class to encapsulate these deeper diagnostics. > Also, isn't it advantageous to allow the client programmer to create > and manipulate any number of prepared statements, rather than just "the > most recent one", as the cx_Oracle-style interface does? Any > sophisticated database module will cache and reuse multiple prepared > statements internally, so why constrain the public interface to > expose just a single prepared statement at a time? If the programmer needs more than one prepared statement, nothing is stopping them from creating more than one cursor. Best regards, Carsten. From davidrushby at yahoo.com Sat Feb 11 18:41:41 2006 From: davidrushby at yahoo.com (David Rushby) Date: Sat, 11 Feb 2006 09:41:41 -0800 (PST) Subject: [DB-SIG] query - prepared statment In-Reply-To: <20060211022816.M53962@uniqsys.com> Message-ID: <20060211174141.84182.qmail@web30009.mail.mud.yahoo.com> --- Carsten Haese wrote: > I'm -1 on introducing a whole new class to encapsulate these deeper > diagnostics. > [...] > If the programmer needs more than one prepared statement, nothing is > stopping them from creating more than one cursor. But this is akin to limiting Connections to having one Cursor open at a time, and saying, "if the programmer needs more than one cursor, nothing is preventing them from creating more than one connection." It's an arbitrary limitation with dubious benefit. The DB API doesn't impose such a limitation in the case of cursors; why do so with prepared statements? > David Rushby wrote: > > However, I would find the cx_Oracle-style interface that Carsten > > described too constraining. Why not let the user create and > manipulate > > as many PreparedStatement objects as desired, and let > > PreparedStatements expose whatever properties and methods are > > appropriate for the database engine, instead of confining the whole > > prepared statement concept to "I'm about to execute this statement > a > > bunch of times, so don't re-prepare it every time". > > > > kinterbasdb.PreparedStatement objects expose properties that > contain: > > - the SQL string on which the PreparedStatement is based > > - a code indicating the statement type (insert, update, delete, > > select, execute procedure, etc.) > > - the plan that the server will use to execute the statement > > - the number of input parameters > > - the number of output parameters > > cursor.description already gives the programmer information about the > output parameters. But currently it's only available after execution. Would you make .description available as a result of a .prepare call, even if .executeXXX hadn't been called yet? If the standard is going to cover statement preparation, it seems sensible to me to separate preparation from execution to the extent that any information available after preparation but before execution is exposed as soon as possible. > Input parameters and the query plan may be hard to standardize in > a meaningful way... I agree that the query plan would be impossible to standardize. But standardizing a metadata representation of input parameters shouldn't be hard. It's already done for output parameters with .description, and input parameters shouldn't theoretically be any more difficult, right? JDBC supports metadata for both input and output parameters. In a prepared SQL statement, both input and output parameters have type information, even if the client programmer chooses to ignore it and rely on the database engine's type coercion so as to be able to provide (e.g.) a string representation of a date instead of an engine-API-specific date object. This type information might not available with an engine such as SQLite, and some engines do provide less information about input parameters than about output parameters, but of course, it's already the case that not every feature of the DB API is supported by every module/engine. This would just be another declaration of intent with defined fallback values for engines/modules that couldn't support every aspect of the feature. > The semantics of query_plan and statement_type will probably have > to be implementation dependent. Yes. > I would suggest that a module that implements statement_type should > also define constants for basic statement types that a statement_type > can be compared to, similar to how type constants work already. Sounds fine. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From carsten at uniqsys.com Sat Feb 11 22:15:21 2006 From: carsten at uniqsys.com (Carsten Haese) Date: Sat, 11 Feb 2006 16:15:21 -0500 Subject: [DB-SIG] query - prepared statment In-Reply-To: <20060211174141.84182.qmail@web30009.mail.mud.yahoo.com> References: <20060211022816.M53962@uniqsys.com> <20060211174141.84182.qmail@web30009.mail.mud.yahoo.com> Message-ID: <20060211202545.M67669@uniqsys.com> On Sat, 11 Feb 2006 09:41:41 -0800 (PST), David Rushby wrote > --- Carsten Haese wrote: > > I'm -1 on introducing a whole new class to encapsulate these deeper > > diagnostics. > > [...] > > If the programmer needs more than one prepared statement, nothing is > > stopping them from creating more than one cursor. > > But this is akin to limiting Connections to having one Cursor open > at a time, and saying, "if the programmer needs more than one cursor, > nothing is preventing them from creating more than one connection." That's a weak analogy. A connection implies a transaction, and requiring the module user to open a second connection to get a second cursor would render the module utterly useless for most cases except extremely trivial ones. On the other hand, asking the module user to obtain a second cursor to prepare two different statements places no undue burden on them. > It's an arbitrary limitation with dubious benefit. The DB API > doesn't impose such a limitation in the case of cursors; why do so with > prepared statements? Of course it's arbitrary, any standard is arbitrary, but it is not a limitation of usability or an impediment to code readability. The proposal of adding an optional .prepare() method and the additional diagnostic attributes on the cursor fits well with the existing API. Adding a whole new class for functionality that can be provided by optional methods and attributes on the cursor is an arbitrary complication with dubious benefit. > > cursor.description already gives the programmer information about the > > output parameters. > > But currently it's only available after execution. Would you make > .description available as a result of a .prepare call, even if > .executeXXX hadn't been called yet? > > If the standard is going to cover statement preparation, it seems > sensible to me to separate preparation from execution to the extent > that any information available after preparation but before execution > is exposed as soon as possible. That's the idea. If a module implements .prepare(), .description and the suggested additional attributes (.input_description, .statement_type, etc., if they're implemented) should be made available after .prepare(). I was remiss in not stating this explicitly. > > Input parameters and the query plan may be hard to standardize in > > a meaningful way... > > I agree that the query plan would be impossible to standardize. > > But standardizing a metadata representation of input parameters > shouldn't be hard. It's already done for output parameters with > .description, and input parameters shouldn't theoretically be any > more difficult, right? JDBC supports metadata for both input and output > parameters. I agree, it should be possible to apply the same semantics of .description to .input_description. Best regards, Carsten. From jlburly at yahoo.com Sun Feb 12 00:30:42 2006 From: jlburly at yahoo.com (Jeff Lewis) Date: Sat, 11 Feb 2006 15:30:42 -0800 (PST) Subject: [DB-SIG] query - prepared statment In-Reply-To: <20060211202545.M67669@uniqsys.com> Message-ID: <20060211233042.75829.qmail@web54606.mail.yahoo.com> --- Carsten Haese wrote: > On Sat, 11 Feb 2006 09:41:41 -0800 (PST), David > Rushby wrote > > --- Carsten Haese wrote: > > > I'm -1 on introducing a whole new class to > encapsulate these deeper > > > diagnostics. > > > [...] > > > If the programmer needs more than one prepared > statement, nothing is > > > stopping them from creating more than one > cursor. > > > > But this is akin to limiting Connections to having > one Cursor open > > at a time, and saying, "if the programmer needs > more than one cursor, > > nothing is preventing them from creating more > than one connection." > > That's a weak analogy. A connection implies a > transaction, ... A connection only implies a transaction when autocommit is either set to true or when a non-autocommit connection is opened, used, committed/rolled back, and finally closed. But what about the case where a connection is cached, as in a connection pool? Pooled connections are used for multiple transactions over time. In the java world, PreparedStatements are often pooled as well. As such, David's analogy seems valid to me. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From carsten at uniqsys.com Sun Feb 12 03:32:21 2006 From: carsten at uniqsys.com (Carsten Haese) Date: Sat, 11 Feb 2006 21:32:21 -0500 Subject: [DB-SIG] query - prepared statment In-Reply-To: <20060211233042.75829.qmail@web54606.mail.yahoo.com> References: <20060211202545.M67669@uniqsys.com> <20060211233042.75829.qmail@web54606.mail.yahoo.com> Message-ID: <20060212012921.M326@uniqsys.com> On Sat, 11 Feb 2006 15:30:42 -0800 (PST), Jeff Lewis wrote > --- Carsten Haese wrote: > > On Sat, 11 Feb 2006 09:41:41 -0800 (PST), David > > Rushby wrote > > > --- Carsten Haese wrote: > > > > I'm -1 on introducing a whole new class to > > encapsulate these deeper > > > > diagnostics. > > > > [...] > > > > If the programmer needs more than one prepared > > statement, nothing is > > > > stopping them from creating more than one > > cursor. > > > > > > But this is akin to limiting Connections to having > > one Cursor open > > > at a time, and saying, "if the programmer needs > > more than one cursor, > > > nothing is preventing them from creating more > > than one connection." > > > > That's a weak analogy. A connection implies a > > transaction, ... > > A connection only implies a transaction when > autocommit is either set to true or when a > non-autocommit connection is opened, used, > committed/rolled back, and finally closed. But what > about the case where a connection is cached, as in a > connection pool? Pooled connections are used for > multiple transactions over time. In the java world, > PreparedStatements are often pooled as well. As such, > David's analogy seems valid to me. Analogies and comparisons to java aside, let's take a rational look at the proposals at hand: 1) Add an optional .prepare() method to the cursor class, and add optional attributes such as .statement_type etc to the cursor class. 2) Introduce a whole new class that would be the result of a .prepare() call, that can be passed to .execute(), and that exposes statement type etc. Both proposals serve the purpose of allowing the programmer to separate statement preparation and execution, and to inspect the properties of a statement before executing it. Proposal 1 is already mostly implemented in at least two DB-API modules (cx_Oracle and mxODBC), and it can easily be implemented in at least one more (InformixDB). Proposal 2 exists in one DB-API module, kinterbasdb. Proposal 1 fits naturally into the existing API. Proposal 2 is a major addition to the existing API and would require clearing up a lot of open questions about its semantics: Can PreparedStatements be executed by a cursor other than the one that prepared them? Can PreparedStatements migrate between threads? Even if these are easy to answer, there may very well be other open questions, and none of them are an issue with Proposal 1. And for all the added complications that come with Proposal 2, it does not seem to offer any benefits that Proposal 1 wouldn't offer as well. I remain +1 on Proposal 1 and -1 on Proposal 2. Marc-Andre, do you have any input on this? You're the one that threw the snowball that set this avalanche in motion ;) Best regards, Carsten. From mal at egenix.com Sun Feb 12 18:30:58 2006 From: mal at egenix.com (M.-A. Lemburg) Date: Sun, 12 Feb 2006 18:30:58 +0100 Subject: [DB-SIG] query - prepared statment In-Reply-To: <20060212012921.M326@uniqsys.com> References: <20060211202545.M67669@uniqsys.com> <20060211233042.75829.qmail@web54606.mail.yahoo.com> <20060212012921.M326@uniqsys.com> Message-ID: <43EF70D2.3040303@egenix.com> Carsten Haese wrote: > Analogies and comparisons to java aside, let's take a rational look at the > proposals at hand: > > 1) Add an optional .prepare() method to the cursor class, and add optional > attributes such as .statement_type etc to the cursor class. > > 2) Introduce a whole new class that would be the result of a .prepare() call, > that can be passed to .execute(), and that exposes statement type etc. > > Both proposals serve the purpose of allowing the programmer to separate > statement preparation and execution, and to inspect the properties of a > statement before executing it. > > Proposal 1 is already mostly implemented in at least two DB-API modules > (cx_Oracle and mxODBC), and it can easily be implemented in at least one more > (InformixDB). Proposal 2 exists in one DB-API module, kinterbasdb. > > Proposal 1 fits naturally into the existing API. Proposal 2 is a major > addition to the existing API and would require clearing up a lot of open > questions about its semantics: Can PreparedStatements be executed by a cursor > other than the one that prepared them? Can PreparedStatements migrate between > threads? Even if these are easy to answer, there may very well be other open > questions, and none of them are an issue with Proposal 1. > > And for all the added complications that come with Proposal 2, it does not > seem to offer any benefits that Proposal 1 wouldn't offer as well. > > I remain +1 on Proposal 1 and -1 on Proposal 2. > > Marc-Andre, do you have any input on this? You're the one that threw the > snowball that set this avalanche in motion ;) Since two database modules already have implemented the .prepare() method more or less, I'd say we go for that in the DB API spec. Note that if we say that .prepare() doesn't have a pre-defined return value, module authors are free to have it return one of the objects mentioned in proposal 2. Furthermore, accepting a special OperationClass object on input to .executexxx() would also be possible - as long as standard strings or Unicode are accepted as well. One thing should be clear though: the .prepare() operation will change the cursor state, so the binding between .prepare() and the cursor is rather tight. Regarding the name of the attribute holding the prepared or last executed statement/command/query/operation, I don't have much of a preference (and yes, you've found a documentation bug there ;-). This attribute is merely meant to serve as input for the .executexxx() methods, but you could just as well store the command somewhere else. Here's the typical use case for .prepare(): cursor.prepare('select * from sometable') ... cursor.execute(cursor.command) It's main purpose is to prepare cursors for the repeated execution of a statement, detect errors in the command prior to actually executing it or accessing meta-data associated with a particular command. Whether or not this actually works (e.g. errors get raised during .prepare()) depends on the database: Some databases don't allow separating the execution from the preparation of a command. In such a situation, the .prepare() method would simply set cursor.command to the given command string. Other databases delay the actual preparation until you fetch meta-data. Yet others, won't give you the meta-data until you actually execute and fetch data on the cursor. For most databases, preparation of a command for execution is a rather time consuming operation, often longer than the execution itself, so using .prepare() would also make sense to prepare complicated queries upfront, e.g. on application startup rather than during request processing. Note that caching prepared cursor may or may not work: rolling back or committing a transaction on a connection may render the cursors created on that connection unusable. In summary, I think we should come up with an interface definition that allows module authors to be creative while still providing a common basis for writing cross-database module applications - this is essentially what the DB API spec has been trying to do all along, while keeping the API simple enough to implement and use. I'm not sure about the other attributes that you were proposing. There's no distinction being made regarding input and output parameters, so I don't understand why you'd want a separate .input_description attribute. Dito for the other attributes. Information such as whether a certain parameter in a stored procedure is an input or output parameter or query plans are not within the scope of the DB API. Module authors should provide database native means for accessing this kind of information. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 12 2006) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From python_eager at yahoo.com Mon Feb 13 07:53:31 2006 From: python_eager at yahoo.com (python eager) Date: Sun, 12 Feb 2006 22:53:31 -0800 (PST) Subject: [DB-SIG] reg Prepared Statment Error Message-ID: <20060213065331.74153.qmail@web36409.mail.mud.yahoo.com> Hi, i am using prepared statment.While passing the value i am getting the following error DatabaseError: ORA-01036: illegal variable name/number Code Snippet : a=cursor.prepare("DELETE FROM PERSONALDETAILS WHERE PID =?") cursor.execute(a,(id)) Please rectify the error regards Python Eager --------------------------------- Brings words and photos together (easily) with PhotoMail - it's free and works with Yahoo! Mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20060212/40ac37b8/attachment.html From andy47 at halfcooked.com Mon Feb 13 12:04:57 2006 From: andy47 at halfcooked.com (Andy Todd) Date: Mon, 13 Feb 2006 22:04:57 +1100 Subject: [DB-SIG] reg Prepared Statment Error In-Reply-To: <20060213065331.74153.qmail@web36409.mail.mud.yahoo.com> References: <20060213065331.74153.qmail@web36409.mail.mud.yahoo.com> Message-ID: <43F067D9.60200@halfcooked.com> python eager wrote: > Hi, > > i am using prepared statment.While passing the value i am getting the > following error > > DatabaseError: ORA-01036: illegal variable name/number > > _Code Snippet :_ > a=cursor.prepare("DELETE FROM PERSONALDETAILS WHERE PID =?") > cursor.execute(a,(id)) > > Please rectify the error > > regards > Python Eager You don't need a prepared statement. Oracle and cx_Oracle will take of this for you. Refer to my previous answer to your questions, the archives of this mailing list are available at http://mail.python.org/pipermail/db-sig/ Your session should be something like; >>> a = cursor.execute("DELETE FROM personaldetails WHERE pid = :pid", {"pid": id}) Or even; >>> a = cursor.execute("DELETE FROM personaldetails WHERE pid = :pid", (id,)) Please try different combinations in an interactive session because this is the best way to find out what works and what doesn't. Regards, Andy -- -------------------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com/ From andy47 at halfcooked.com Thu Feb 16 01:40:43 2006 From: andy47 at halfcooked.com (Andy Todd) Date: Thu, 16 Feb 2006 11:40:43 +1100 Subject: [DB-SIG] reg cursor.fetchall() In-Reply-To: <43E9CB84.5050204@halfcooked.com> References: <20060208040820.78281.qmail@web36404.mail.mud.yahoo.com> <43E9CB84.5050204@halfcooked.com> Message-ID: <43F3CA0B.6050405@halfcooked.com> Andy Todd wrote: > python eager wrote: >> Hi , This is my statment which will work fine. but the statment line is >> long. How to split up these lines . >> >> *Code Snippet :* >> >> for PID,FIRSTNAME,MIDDLENAME,LASTNAME, >> MARITALSTATUS,EMPLOYEESTATUS,NOD,SALARY, >> POI,RADDRESS,OADDRESS,MNO,LNO,DOBD,DOBM, >> DOBY,DOID,DOIM,DOIY,DOED,DOEM,DOEY in cursor.fetchall(): >> >> Please help me >> >> regards >> Python Eager >> >> >> _______________________________________________ >> DB-SIG maillist - DB-SIG at python.org >> http://mail.python.org/mailman/listinfo/db-sig > > The usual pattern is something like (untested, please ignore syntax errors); > > >>> myCursor.execute("SELECT x,y,z FROM tablea") > >>> for row in cursor.fetchall(): > ... print "Column x:", row[0] > ... print "y * z = %d" % (row[1] * row[2]) > > e.g. return each row of your results into a tuple and then reference the > individual elements by index. > > Sadly cx_Oracle doesn't offer different cursor classes like, for > instance, MySQLdb; > > http://dustman.net/andy/python/MySQLdb_obsolete/doc/MySQLdb-4.html#usage > > So you can't refer to cursor results as dictionaries or other sequence > types. > > Regards, > Andy Of course, two minutes with Google offers up a couple of alternatives from the Python Cookbook. First, and along the sames lines as the solutions provided by Andy and Carsten we have this recipe; http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52293 Which I think is rather trumped by an alternative that uses Greg Stein's dtuple[1] module; http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/81252 There's also a mention in the comments of the Opal Group's db_row module[2]. [1] http://www.lyra.org/greg/python/dtuple.py [2] http://opensource.theopalgroup.com/files/db_row.txt Regards, Andy -- -------------------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com/ From python_eager at yahoo.com Tue Feb 21 06:13:54 2006 From: python_eager at yahoo.com (python eager) Date: Mon, 20 Feb 2006 21:13:54 -0800 (PST) Subject: [DB-SIG] How to upload a file? Message-ID: <20060221051354.61090.qmail@web31301.mail.mud.yahoo.com> Hi how to upload & open a file in python. Please send the code snippet . It is very helpful in my project. Please help me bye Thank you regards Python Eager --------------------------------- What are the most popular cars? Find out at Yahoo! Autos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20060220/4fe92b80/attachment.htm From chris at cogdon.org Tue Feb 21 06:39:07 2006 From: chris at cogdon.org (Chris Cogdon) Date: Mon, 20 Feb 2006 21:39:07 -0800 Subject: [DB-SIG] How to upload a file? In-Reply-To: <20060221051354.61090.qmail@web31301.mail.mud.yahoo.com> References: <20060221051354.61090.qmail@web31301.mail.mud.yahoo.com> Message-ID: On Feb 20, 2006, at 9:13 PM, python eager wrote: > Hi > how to upload & open a file in python. Please send the code > snippet . It is very helpful in my project. > Please help me What database are you using? :) ("`-/")_.-'"``-._ Chris Cogdon . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL From python_eager at yahoo.com Tue Feb 21 07:05:48 2006 From: python_eager at yahoo.com (python eager) Date: Mon, 20 Feb 2006 22:05:48 -0800 (PST) Subject: [DB-SIG] How to upload a file in Oracle 9i? In-Reply-To: Message-ID: <20060221060548.43235.qmail@web31310.mail.mud.yahoo.com> Hi > how to upload & open a file in python. Please send the code > snippet . It is very helpful in my project.i am using Oracle 9i. > Please help me regards Python Eager --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20060220/c02df3ee/attachment.html From python_eager at yahoo.com Wed Feb 22 05:44:49 2006 From: python_eager at yahoo.com (python eager) Date: Tue, 21 Feb 2006 20:44:49 -0800 (PST) Subject: [DB-SIG] Doubt in File Uploading? Message-ID: <20060222044449.38829.qmail@web31308.mail.mud.yahoo.com> Hi > how to upload & open a file in python. Please send the code > snippet . It is very helpful in my project.i am using Oracle 9i. For example store msword doucment & Excel doucment. Thereafter this can be open in same software where it is stored. > Please help me regards Python Eager --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20060221/6c8c1374/attachment.htm From chris at cogdon.org Wed Feb 22 06:06:52 2006 From: chris at cogdon.org (Chris Cogdon) Date: Tue, 21 Feb 2006 21:06:52 -0800 Subject: [DB-SIG] Doubt in File Uploading? In-Reply-To: <20060222044449.38829.qmail@web31308.mail.mud.yahoo.com> References: <20060222044449.38829.qmail@web31308.mail.mud.yahoo.com> Message-ID: <4B093CE5-90B1-468B-A7EE-A4A09E28C98B@cogdon.org> On Feb 21, 2006, at 8:44 PM, python eager wrote: > Hi > > how to upload & open a file in python. Please send the code > > snippet . It is very helpful in my project.i am using Oracle 9i. > For example store msword doucment & Excel doucment. Thereafter this > can be open in same software where it is stored. > > > Please help me I don't use oracle 9i, but here's the BASIC steps you'll need to go through. * Create a schema with a column that can store binary objects. * Use an INSERT statement that inserts your word document as one of the attributes. When retriving with a SELECT, send it out to the web server like this: print "Content-Type: application/ms-word" print print returned_contents_from_select That's it... but... you'll still need to learn a fair bit to get all this working, and unless someone here is feeling especially helpful, you'll need to learn this yourself. db-sig isn't a free programming contract shop, we're here to help you with the database interfaces with python, and it soounds like you need a LOT more help than that. -- ("`-/")_.-'"``-._ Chris Cogdon . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL From rshzky at yahoo.com Wed Feb 22 13:47:45 2006 From: rshzky at yahoo.com (Rasha Ebo) Date: Wed, 22 Feb 2006 04:47:45 -0800 (PST) Subject: [DB-SIG] platypus Code Message-ID: <20060222124745.90318.qmail@web30406.mail.mud.yahoo.com> Peace be upon you, I use the platypus example in reportlab's user guide chapter 5 page 59 to build up a Doctemplate with flowables 'paraghrap' and 'spacer' (it is used to create 100 fixed-content paraghrap with spacer between paragraphs) and it worked well then I added to this example, the code of the 'Table' follwable in page 73 chapter 7 which used a variable called 'data' to hold the data of the table (code is provided at the end) When the value of data is: data= [['00', '01', '02', '03', '04'], ['10', '11', '12', '13', '14'], ['10', '11', '12', '13', '14'], ['30', '31', '32', '33', '34']] and no of the repeating the paraghraphes wsa set to 100 , an error was raised saying: reportlab.platypus.doctemplate.LayoutError: Flowable with cell(0,0) containing '00' too large on page 13 At the begining, I thought it is a problem of splitting table across multiple pages but it is not because when I changed the value of data to be: data= [['00', '01', '02', '03', '04'], ['10', '11', '12', '13', '14']] and kept the no of the repeating the paraghraphes the same as above (100 times) , No error has been raised and a table was splitted perfectly across 2 pages then I changed the data value to be: data= [['00', '01', '02', '03', '04'], ['10', '11', '12', '13', '14'], ['10', '11', '12', '13', '14'], ['30', '31', '32', '33', '34']] but I changed the no of the repeating the paraghraphes to 54 or less and it works well but with 55 or more, it fails. And by more experiments I have found that if cut down the length of the table data and increase the repetition number of the paragraph, it can work well and viseversa Can anybody explain to me what is the point that rules this behaviour, is it the number of charcters per page or per table cell or what? I will highlight the code line which sets the value of the table and the cosde line which determines the no of repetition I hope I have made my question clear and thanks very much for yor help (N.B I am a newbebi) Thanks a lot Code: platypusgo = """ def go(): doc = SimpleDocTemplate("phello.pdf") Story = [Spacer(1,2*inch)] style = styles["Normal"] data= [['00', '01', '02', '03', '04'], ['10', '11', '12', '13', '14'], ['10', '11', '12', '13', '14'], ['30', '31', '32', '33', '34']] t=Table(data) t.setStyle(TableStyle([('BACKGROUND',(1,1),(1,-1),green),('TEXTCOLOR',(0,0),(1,-1),red)])) for i in range(100): bogustext = ("This is Paragraph number %s. " % i) *20 p = Paragraph(bogustext, style) Story.append(p) Story.append(Spacer(1,0.2*inch)) Story.append(t) doc.build(Story, onFirstPage=myFirstPage, onLaterPages=myLaterPages) #Finally build up your DocTemplate """ #------------Execute the page code----------------------------------- if __name__=="__main__": # then do the platypus hello world for b in platypussetup, platypusfirstpage, platypusnextpage, platypusgo: b = strip(b) print b exec(b+'\n') go() --------------------------------- Yahoo! Mail Use Photomail to share photos without annoying attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20060222/f4b20419/attachment.html From mal at egenix.com Wed Feb 22 14:53:34 2006 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 22 Feb 2006 14:53:34 +0100 Subject: [DB-SIG] platypus Code In-Reply-To: <20060222124745.90318.qmail@web30406.mail.mud.yahoo.com> References: <20060222124745.90318.qmail@web30406.mail.mud.yahoo.com> Message-ID: <43FC6CDE.8070706@egenix.com> Rasha Ebo wrote: > Peace be upon you, Thanks, but I think you posted this to the wrong mailing list. db-sig is about relational databases. You question sounds more related to ReportLab's PDF lib. > I use the platypus example in reportlab's user guide chapter 5 page 59 to build up a Doctemplate with flowables 'paraghrap' and 'spacer' (it is used to create 100 fixed-content paraghrap with spacer between paragraphs) and it worked well then I added to this example, the code of the 'Table' follwable in page 73 chapter 7 which used a variable called 'data' to hold the data of the table (code is provided at the end) > > When the value of data is: > data= [['00', '01', '02', '03', '04'], > ['10', '11', '12', '13', '14'], > ['10', '11', '12', '13', '14'], > ['30', '31', '32', '33', '34']] > and no of the repeating the paraghraphes wsa set to 100 > , an error was raised saying: > > reportlab.platypus.doctemplate.LayoutError: Flowable
with cell(0,0) containing '00' too large on page 13 > > At the begining, I thought it is a problem of splitting table across multiple pages but it is not because when I changed the value of data to be: > > data= [['00', '01', '02', '03', '04'], > ['10', '11', '12', '13', '14']] > and kept the no of the repeating the paraghraphes the same as above (100 times) > , No error has been raised and a table was splitted perfectly across 2 pages > > then I changed the data value to be: > > data= [['00', '01', '02', '03', '04'], > ['10', '11', '12', '13', '14'], > ['10', '11', '12', '13', '14'], > ['30', '31', '32', '33', '34']] > but I changed the no of the repeating the paraghraphes to 54 or less and it works well but with 55 or more, it fails. > And by more experiments I have found that if cut down the length of the table data and increase the repetition number of the paragraph, it can work well and viseversa > > Can anybody explain to me what is the point that rules this behaviour, is it the number of charcters per page or per table cell or what? > > I will highlight the code line which sets the value of the table and the cosde line which determines the no of repetition > > I hope I have made my question clear and thanks very much for yor help > (N.B I am a newbebi) > > Thanks a lot > > Code: > > platypusgo = """ > def go(): > doc = SimpleDocTemplate("phello.pdf") > Story = [Spacer(1,2*inch)] > style = styles["Normal"] > data= [['00', '01', '02', '03', '04'], > ['10', '11', '12', '13', '14'], > ['10', '11', '12', '13', '14'], > ['30', '31', '32', '33', '34']] > t=Table(data) > t.setStyle(TableStyle([('BACKGROUND',(1,1),(1,-1),green),('TEXTCOLOR',(0,0),(1,-1),red)])) > for i in range(100): > bogustext = ("This is Paragraph number %s. " % i) *20 > p = Paragraph(bogustext, style) > Story.append(p) > Story.append(Spacer(1,0.2*inch)) > Story.append(t) > doc.build(Story, onFirstPage=myFirstPage, onLaterPages=myLaterPages) #Finally build up your DocTemplate > """ > > #------------Execute the page code----------------------------------- > if __name__=="__main__": > # then do the platypus hello world > for b in platypussetup, platypusfirstpage, platypusnextpage, platypusgo: > b = strip(b) > print b > exec(b+'\n') > go() > > > --------------------------------- > Yahoo! Mail > Use Photomail to share photos without annoying attachments. > > > ------------------------------------------------------------------------ > > _______________________________________________ > DB-SIG maillist - DB-SIG at python.org > http://mail.python.org/mailman/listinfo/db-sig -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 22 2006) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From python_eager at yahoo.com Thu Feb 23 05:29:22 2006 From: python_eager at yahoo.com (python eager) Date: Wed, 22 Feb 2006 20:29:22 -0800 (PST) Subject: [DB-SIG] reg File Reading Message-ID: <20060223042922.89256.qmail@web31311.mail.mud.yahoo.com> Hi, This is my code snippet. This code will not read the characters in Ms Word Document. I got the below output. But if i use any txt format this will be display properly. Instead of txt format i am using doc format. I got error while reading. please help me to solve this problem req = self.request() inp = file('C:\\Python.doc','r') for line in inp: self.writeln(line) inp.close() Output : ????? regards Python eager --------------------------------- Relax. Yahoo! Mail virus scanning helps detect nasty viruses! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20060222/48ec0eb3/attachment.htm From andy47 at halfcooked.com Thu Feb 23 12:34:28 2006 From: andy47 at halfcooked.com (Andy Todd) Date: Thu, 23 Feb 2006 22:34:28 +1100 Subject: [DB-SIG] reg File Reading In-Reply-To: <20060223042922.89256.qmail@web31311.mail.mud.yahoo.com> References: <20060223042922.89256.qmail@web31311.mail.mud.yahoo.com> Message-ID: <43FD9DC4.8020708@halfcooked.com> python eager wrote: > Hi, > This is my code snippet. This code will not read the characters in Ms > Word Document. I got the below output. But if i use any *txt* format > this will be display properly. Instead of txt format i am using doc > format. I got error while reading. please help me to solve this problem > > > req = self.request() > inp = file('C:\\Python.doc','r') > for line in inp: > self.writeln(line) > inp.close() > > *Output :* > * ?????* > > regards! > Python eager > > Your code will read and process a text file. Microsoft Word produces binrary files. Please RTFM. This is not a database question. If after consulting http://docs.python.org http://www.diveintopython.org and http://aspn.activestate.com/ASPN/Python/Cookbook/ you still don't have a solution I'd suggest you ask on comp.lang.python Regards, Andy -- -------------------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com/ From python at venix.com Thu Feb 23 13:21:10 2006 From: python at venix.com (Python) Date: Thu, 23 Feb 2006 07:21:10 -0500 Subject: [DB-SIG] reg File Reading In-Reply-To: <43FD9DC4.8020708@halfcooked.com> References: <20060223042922.89256.qmail@web31311.mail.mud.yahoo.com> <43FD9DC4.8020708@halfcooked.com> Message-ID: <1140697270.17747.559.camel@www.venix.com> On Thu, 2006-02-23 at 22:34 +1100, Andy Todd wrote: > python eager wrote: > > Hi, > > This is my code snippet. This code will not read the characters in Ms > > Word Document. I got the below output. But if i use any *txt* format > > this will be display properly. Instead of txt format i am using doc > > format. I got error while reading. please help me to solve this problem > > > > > > req = self.request() > > inp = file('C:\\Python.doc','r') > > for line in inp: > > self.writeln(line) > > inp.close() > > > > *Output :* > > * ?????* > > > > regards! > > Python eager > > > > > > Your code will read and process a text file. Microsoft Word produces > binrary files. Please RTFM. > > This is not a database question. If after consulting > http://docs.python.org http://www.diveintopython.org and > http://aspn.activestate.com/ASPN/Python/Cookbook/ you still don't have a > solution I'd suggest you ask on comp.lang.python > > Regards, > Andy Actually the Python Tutor list will help you with these kinds of problems. Please sign up and send your questions to the Tutors. http://www.python.org/mailman/listinfo/tutor Here is the beginner guide page from the Python Web site. http://wiki.python.org/moin/BeginnersGuide -- Lloyd Kvam Venix Corp