From gvanrossum at gmail.com Fri Oct 8 17:51:19 2004 From: gvanrossum at gmail.com (Guido van Rossum) Date: Fri Oct 8 17:51:31 2004 Subject: [DB-SIG] Re: [Python-Dev] Toward Python's future article In-Reply-To: <416655CA.1020006@egenix.com> References: <002301c4acc9$10a26a60$5bae2c81@oemcomputer> <864d370904100717246f51e6fa@mail.gmail.com> <416655CA.1020006@egenix.com> Message-ID: On Fri, 08 Oct 2004 10:54:34 +0200, M.-A. Lemburg wrote: > If you feel that a certain feature is missing, I'd suggest > you direct your constructive criticism to the db-sig@python.org. OK, I'll bite. I would like the spec to change to require new versions of db API compatible modules to fully support the built-in datetime type, at least when used with Python 2.4 and beyond. The spec current recommends use of a 3rd party date/time type, which was a good idea back when there was no built-in alternative, but which should gradually be phased out now that there is. I don't want to make this requirement when using Python 2.3 or before, because the datetime type didn't have a C API then (thanks to Anthony Tuininga for contributing it to 2.4!). In the remote future, all db-API compatible modules should be required to support the datetime module, but I want to provide for a reasonable transitional period. A general comment: as specs go, the db-API spec is leaning rather far towards giving different implementations freedom to do things differently. I know this is standard practice in the SQL world, and where it makes sense I support it (such as differences in support for threading, or variations in SQL syntax). But in other areas I think there are differences that make switching databases more painful than necessary, and I would like to push implementers gently towards more uniformity. I wish I could push for a standard parameter transfer mechanism, but I expect that this is often constrained by the underlying native APIs provided by various db vendors. Yet, I wish we could reach the level of standardization found in JDBC. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From mal at egenix.com Fri Oct 8 18:19:22 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Oct 8 18:19:27 2004 Subject: [DB-SIG] Re: [Python-Dev] Toward Python's future article In-Reply-To: References: <002301c4acc9$10a26a60$5bae2c81@oemcomputer> <864d370904100717246f51e6fa@mail.gmail.com> <416655CA.1020006@egenix.com> Message-ID: <4166BE0A.90600@egenix.com> Guido van Rossum wrote: > On Fri, 08 Oct 2004 10:54:34 +0200, M.-A. Lemburg wrote: > > >>If you feel that a certain feature is missing, I'd suggest >>you direct your constructive criticism to the db-sig@python.org. > > > OK, I'll bite. I would like the spec to change to require new versions > of db API compatible modules to fully support the built-in datetime > type, at least when used with Python 2.4 and beyond. The spec current > recommends use of a 3rd party date/time type, which was a good idea > back when there was no built-in alternative, but which should > gradually be phased out now that there is. I don't want to make this > requirement when using Python 2.3 or before, because the datetime type > didn't have a C API then (thanks to Anthony Tuininga for contributing > it to 2.4!). Agreed, we should recommend usage of the datetime objects starting with Python 2.4. I wouldn't want to make it a requirement, though, since the DB API is defined in terms of API signatures, not specific objects, e.g. a module author should have the freedom to continue to use e.g. mxDateTime, tuples or strings or leave the choice of data type to the users. > In the remote future, all db-API compatible modules should be required > to support the datetime module, but I want to provide for a reasonable > transitional period. > > A general comment: as specs go, the db-API spec is leaning rather far > towards giving different implementations freedom to do things > differently. I know this is standard practice in the SQL world, and > where it makes sense I support it (such as differences in support for > threading, or variations in SQL syntax). But in other areas I think > there are differences that make switching databases more painful than > necessary, and I would like to push implementers gently towards more > uniformity. > > I wish I could push for a standard parameter transfer mechanism, but I > expect that this is often constrained by the underlying native APIs > provided by various db vendors. Yet, I wish we could reach the level > of standardization found in JDBC. JDBC is more like an OO-wrapper on top of the low-level API defined by the DB API. As I've mentioned quite a few times on this list, it is well possible to write an abstraction layer on top of the existing database modules that exposes a JDBC-like API or a uniform DB-API 2.0 like interface (e.g. http://sourceforge.net/projects/pydal/) given a set of DB-API 2.0 compatible database drivers. Think of the DB API as a driver interface specification to make a module compatible to such a more abstract database manager. A specification of such a database manager interface is something that can well be done without requiring all database modules to implement the complete (and possibly complicated) set of features. The whole point of the DB API spec is to make things easy for the database module author, so anything which goes beyond the low-level nature of this interface should be left to a separate specification. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 08 2004) >>> 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 chris at cogdon.org Fri Oct 8 18:43:43 2004 From: chris at cogdon.org (Chris Cogdon) Date: Fri Oct 8 18:44:00 2004 Subject: [DB-SIG] Re: [Python-Dev] Toward Python's future article In-Reply-To: <4166BE0A.90600@egenix.com> References: <002301c4acc9$10a26a60$5bae2c81@oemcomputer> <864d370904100717246f51e6fa@mail.gmail.com> <416655CA.1020006@egenix.com> <4166BE0A.90600@egenix.com> Message-ID: <37030E8A-1949-11D9-AD46-000A95E3823E@cogdon.org> On Oct 8, 2004, at 09:19, M.-A. Lemburg wrote: > I wouldn't want to make it a requirement, though, since the DB API > is defined in terms of API signatures, not specific objects, e.g. a > module author should have the freedom to continue to use e.g. > mxDateTime, > tuples or strings or leave the choice of data type to the users. > The whole point of the DB API spec is to make things easy for the > database module author, so anything which goes beyond the low-level > nature of this interface should be left to a separate specification. In my humble opinion, and with all the proper deference to those that have written excellent and useful code, I disagree (and have always, in the past on this list) with the above two statements. Giving the module author a choice in implementation is great, but given them a choice in the data-type being returned just pushes the problem of dealing with differing data types onto the application writer. Making things 'easy for the module writer' is well and good... it gets a useful module out there quicker and with fewer bugs, but this makes it harder for the application writer, and I don't think that should be the focus. After all, the 'hard job' of writing the module is only done once (or, really, just a few times, for each database type and each person that decides to put the effort in to create a variation), but the job of writing applications is done over and over. I think it SHOULD BE the job of the module writer (whether it's a DB interface, or an interface to the operating system) to deal with all the vagaries of the underlying layers and present a consistent (as far as possible) interface to the application writer. I appreciate that this is much harder with something like a DB interface, but for something as simple as date/time return types, it should be mandated. Otherwise, it's like saying "the module writer has the choice of returning integer values as a int, long, or a string, and it's up to the application writer to deal with it". -- ("`-/")_.-'"``-._ Chris Cogdon . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL From gvanrossum at gmail.com Sat Oct 9 01:58:42 2004 From: gvanrossum at gmail.com (Guido van Rossum) Date: Sat Oct 9 01:58:50 2004 Subject: [DB-SIG] Re: [Python-Dev] Toward Python's future article In-Reply-To: <4166BE0A.90600@egenix.com> References: <002301c4acc9$10a26a60$5bae2c81@oemcomputer> <864d370904100717246f51e6fa@mail.gmail.com> <416655CA.1020006@egenix.com> <4166BE0A.90600@egenix.com> Message-ID: > Agreed, we should recommend usage of the datetime objects > starting with Python 2.4. > > I wouldn't want to make it a requirement, though, since the DB API > is defined in terms of API signatures, not specific objects, e.g. a > module author should have the freedom to continue to use e.g. mxDateTime, > tuples or strings or leave the choice of data type to the users. Well, that's exactly what I'm hoping to get rid of in the future. By prescribing the use of datetime (for results -- it may remain optional for input values), we implicitly support a much larger set of API signatures for those results that users can depend on. Right now, if you want to do anything useful with a result representing a timestamp, you have to turn it into some other date/time object first whose API you know. > JDBC is more like an OO-wrapper on top of the low-level API defined > by the DB API. I dunno.The db-API is pretty OO itself, and many of the db-API interfaces feel higher-level than corresponding things in JDBC. I just *love* how easy it is in Python to open a database, create a cursor, execute a SELECT and retrieve the results. JDBC requires much more work. > As I've mentioned quite a few times on this list, it is well > possible to write an abstraction layer on top of the existing > database modules that exposes a JDBC-like API or a uniform > DB-API 2.0 like interface (e.g. http://sourceforge.net/projects/pydal/) > given a set of DB-API 2.0 compatible database drivers. Maybe the latter is the way to go. Although I still think it's a shame we need it at all, given how much the db-API alrady gets right. > Think of the DB API as a driver interface specification to make > a module compatible to such a more abstract database manager. > > A specification of such a database manager interface is something > that can well be done without requiring all database modules to > implement the complete (and possibly complicated) set of features. > > The whole point of the DB API spec is to make things easy for the > database module author, so anything which goes beyond the low-level > nature of this interface should be left to a separate specification. Sure, but that's putting the db implementer's convenience well ahead of the user's convenience. At some point, those db implementers that put the user's convenience first will gain the upper hand (as the demise of DCOracle in favor of cx_Oracle has shown). -- --Guido van Rossum (home page: http://www.python.org/~guido/) From jfranz at neurokode.com Sat Oct 9 08:28:12 2004 From: jfranz at neurokode.com (Jonathan M. Franz) Date: Sat Oct 9 08:29:51 2004 Subject: [DB-SIG] Re: [Python-Dev] Toward Python's future article Message-ID: <416784FC.10102@neurokode.com> [MAL] >>/ I wouldn't want to make it a requirement, though, since the DB API />>/ is defined in terms of API signatures, not specific objects, e.g. a />>/ module author should have the freedom to continue to use e.g. mxDateTime, />>/ tuples or strings or leave the choice of data type to the users. /[GvR] >Well, that's exactly what I'm hoping to get rid of in the future. By >prescribing the use of datetime (for results -- it may remain optional >for input values), we implicitly support a much larger set of API >signatures for those results that users can depend on. Right now, if >you want to do anything useful with a result representing a timestamp, >you have to turn it into some other date/time object first whose API >you know. I agree with GvR: I think others do as well. I even think there was a grant proposal that mentioned this issue. *wink* It is a change that will break things - but if it makes the end-users lives easier, I'm for it. Then again, I'm biased (having written the grant proposal and such). [MAL] >>/ JDBC is more like an OO-wrapper on top of the low-level API defined />>/ by the DB API. /[GvR] >I dunno.The db-API is pretty OO itself, and many of the db-API >interfaces feel higher-level than corresponding things in JDBC. I just >*love* how easy it is in Python to open a database, create a cursor, >execute a SELECT and retrieve the results. JDBC requires much more >work. Jython improves on the usability of JDBC alot, but it is (like most Java APIs) still very verbose. Java in general just requires too much boilerplate code. [MAL] >>/ As I've mentioned quite a few times on this list, it is well />>/ possible to write an abstraction layer on top of the existing />>/ database modules that exposes a JDBC-like API or a uniform />>/ DB-API 2.0 like interface (e.g. http://sourceforge.net/projects/pydal/) />>/ given a set of DB-API 2.0 compatible database drivers. /[GvR] >Maybe the latter is the way to go. Although I still think it's a shame >we need it at all, given how much the db-API alrady gets right. I think a driver/user-api split is, although painful, the way to go. Perl, JDBC, ADO and others all do this. That said, there are things missing in the 'driver layer' that (as a maintainer of a wrapper module) would be exceedingly useful. Catalog inspection comes to mind - hiding the SQL (if any) used by the DB to get the list of databases/tables/columns. [MAL] >>/ Think of the DB API as a driver interface specification to make />>/ a module compatible to such a more abstract database manager. />>/ />>/ A specification of such a database manager interface is something />>/ that can well be done without requiring all database modules to />>/ implement the complete (and possibly complicated) set of features. />>/ />>/ The whole point of the DB API spec is to make things easy for the />>/ database module author, so anything which goes beyond the low-level />>/ nature of this interface should be left to a separate specification. //I think co-operation in this case would be beneficial to both 'sides'. //I agree that we shouldn't make life _too_ hard for the driver creators, but some give-and-take would need to exist between such a database-manager-interface group and the driver spec (DBAPI). In my grant proposal, I called this layer the 'user layer'. Example 1: Type listing in the driver/DBAPI module. Some modules support the basic types in the standard, others extend them with more specific types such as LOB (cx_Oracle) - while dir() and documentation is useful to find these for a human, the 'user layer'(wrapper) needs to either support just the minimum types (which may break things when a query is executed), or know about all the types in the driver/DBAPI module ahead of time. These type issues come into play when implementing things such as editable resultsets/records (one of the finest features of ADO). Some hints and/or changes might be needed at the underlying DBAPI/driver layer to support this higher-level feature without severe limitations/kludgyness (as I have experienced firsthand). My list of possible extensions is long - some have been discussed here before - but not much movement has been made forward. /Anyway - my point is - we'll have to work on the driver/DBAPI spec as well as the user-layer as a whole to get a truly usable and better system. Switching to datetime types is just a start, IMHO. [GvR] >Sure, but that's putting the db implementer's convenience well ahead >of the user's convenience. At some point, those db implementers that >put the user's convenience first will gain the upper hand (as the >demise of DCOracle in favor of cx_Oracle has shown). Unless a standard set of extensions, or a new higher-level standard is defined, the extensions some modules provide could hamper the overall acceptance/usage of the system. And, for those writing the user-layer, such extensions can be a big pain - do you write a specific exception to expose the feature of this single module - or do you ignore it? I think the community should work together on this to move things forward in such a way that the user's convenience is kept in mind, but we don't burden the module authors too much - and that the provided conveniences are available to users of all RDBMs, not just a subset. And yes, once again, I have made an overly verbose post :) ~Jon Franz NeuroKode Labs, LLC From pf_moore at yahoo.co.uk Sat Oct 9 21:47:18 2004 From: pf_moore at yahoo.co.uk (Paul Moore) Date: Sat Oct 9 21:47:26 2004 Subject: [DB-SIG] Re: [Python-Dev] Toward Python's future article References: <002301c4acc9$10a26a60$5bae2c81@oemcomputer> <864d370904100717246f51e6fa@mail.gmail.com> <416655CA.1020006@egenix.com> <4166BE0A.90600@egenix.com> Message-ID: "M.-A. Lemburg" writes: > Agreed, we should recommend usage of the datetime objects > starting with Python 2.4. Good. > I wouldn't want to make it a requirement, though, since the DB API > is defined in terms of API signatures, not specific objects, e.g. a > module author should have the freedom to continue to use e.g. mxDateTime, > tuples or strings or leave the choice of data type to the users. I'm not sure I follow this. From the point of view of a *user* of a DB-API compatible module, the fact that I can't know how to manipulate a returned datetime value, without using driver-specific code to convert the value to a native Python datetime value, is a major disadvantage. Later in your post, you make it clear that you are working from the *implementer's* point of view. As has been stated elsewhere, this is OK in terms of getting compatible modules available as easily as possible, but we're beyond that point now, and it's time to start pushing a more user-centric approach. If this means that the API gets more prescriptive, then so be it. But it's early days yet for datetime. I don't honestly see drivers *not* migrating to use it as they are upgraded. Paul. -- The trouble with being punctual is that nobody's there to appreciate it. -- Franklin P. Jones From mal at egenix.com Mon Oct 11 18:41:47 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Oct 11 18:41:51 2004 Subject: [DB-SIG] Re: [Python-Dev] Toward Python's future article In-Reply-To: References: <002301c4acc9$10a26a60$5bae2c81@oemcomputer> <864d370904100717246f51e6fa@mail.gmail.com> <416655CA.1020006@egenix.com> <4166BE0A.90600@egenix.com> Message-ID: <416AB7CB.8090600@egenix.com> Guido van Rossum wrote: >>Agreed, we should recommend usage of the datetime objects >>starting with Python 2.4. >> >>I wouldn't want to make it a requirement, though, since the DB API >>is defined in terms of API signatures, not specific objects, e.g. a >>module author should have the freedom to continue to use e.g. mxDateTime, >>tuples or strings or leave the choice of data type to the users. > > Well, that's exactly what I'm hoping to get rid of in the future. Fixing mappings of database data types to Python data types would be a step backwards rather than forward in terms of user friendliness and ability of the database module authors to provide the users with the most suitable Python type or interface for the data types supported by the database backends. The DB API specification has always left the mapping open and did so on purpose, because databases tend to invent new data types with each new release. Most database types do not have obvious mappings to Python types, which is why the choice of supported types is left to the database module author. Ideal would be to have the user configure the database modules to return certain types depending on the database column type. Some interfaces already provide methods to allow for this kind of configuration. It would be great if we could find a standardized way to make these adjustments. The DB API would then provide a suggested list of Python types which should be made available by the database interface for the most common database data types. Users could then tell the database module what to return on output to both avoid extensive post-processing and accomodate for user preferences. > By prescribing the use of datetime (for results -- it may remain optional > for input values), we implicitly support a much larger set of API > signatures for those results that users can depend on. Right now, if > you want to do anything useful with a result representing a timestamp, > you have to turn it into some other date/time object first whose API > you know. I'm not sure I follow you here: the database modules usually do document which object types they use on output and recognize on input. As for date/time values: the vast majority of modules use or can be configured to use mxDateTime objects to return date/time values from the database, so for this particular data type there are few surprises. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 11 2004) >>> 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 chris at cogdon.org Mon Oct 11 19:21:01 2004 From: chris at cogdon.org (Chris Cogdon) Date: Mon Oct 11 19:21:09 2004 Subject: [DB-SIG] Re: [Python-Dev] Toward Python's future article In-Reply-To: <416AB7CB.8090600@egenix.com> References: <002301c4acc9$10a26a60$5bae2c81@oemcomputer> <864d370904100717246f51e6fa@mail.gmail.com> <416655CA.1020006@egenix.com> <4166BE0A.90600@egenix.com> <416AB7CB.8090600@egenix.com> Message-ID: On Oct 11, 2004, at 09:41, M.-A. Lemburg wrote: > I'm not sure I follow you here: the database modules usually do > document which object types they use on output and recognize on > input. Its all very well to document it, but it means that differing database connectors can still return different types, even when staying on the same back-end database. In other words, this is still 'module-centric' rather than 'application-centric'. Yes, I agree that database with very strange types (such as PostgreSQL's line and shape types), the module-writer is going to have to come up with unique python types, but things like 'date' are as stable as 'int'. I DO like the idea of feeding handlers to the database, so the application writer can decide what kind of types to return in what circumstances. And... I'd like to point out that if more application-writer-centric features are put into DB-API 3.0, it does not preclude a module writer continuing to write to DB-API 2.0 instead (and, perhaps, letting someone else write a 3.0 wrapper) -- ("`-/")_.-'"``-._ Chris Cogdon . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL From kshahzadbutt at gmail.com Tue Oct 12 22:18:46 2004 From: kshahzadbutt at gmail.com (Khawaja-Shahzad Butt) Date: Tue Oct 12 22:18:51 2004 Subject: [DB-SIG] Problem with mxODBC insert statement Message-ID: Hello, I don't know how to use SQL which way for mxODBC and python. I used this statement and got this error. q= "INSERT INTO rss_feed_items(item_date,item_title,item_author,item_permalink,item_description)\ VALUES(%s)"%(item_dmodified); MS SQL server 2000 gave me this error for above query statement: ProgrammingError: ('37000', 170, "[Microsoft][ODBC SQL Server Driver][SQL Server]Line 1: Incorrect syntax near '06'.", 4612) or can i use the ? instead of %s can you give me example since there is none in egenix manual for mxODBC. What am i doing wrong. Also should always use auto_commit while using mxODBC Please reply. Thank you, Regards Shahzad From chris at cogdon.org Tue Oct 12 22:27:55 2004 From: chris at cogdon.org (Chris Cogdon) Date: Tue Oct 12 22:28:09 2004 Subject: [DB-SIG] Problem with mxODBC insert statement In-Reply-To: References: Message-ID: <32AFAD88-1C8D-11D9-B38E-000A95E3823E@cogdon.org> On Oct 12, 2004, at 13:18, Khawaja-Shahzad Butt wrote: > Hello, > > I don't know how to use SQL which way for mxODBC and > python. I used this statement and got this error. > > q= "INSERT INTO > rss_feed_items(item_date,item_title,item_author,item_permalink,item_des > cription)\ > VALUES(%s)"%(item_dmodified); > > MS SQL server 2000 gave me this error for above query statement: > > ProgrammingError: ('37000', 170, "[Microsoft][ODBC SQL Server > Driver][SQL Server]Line 1: Incorrect syntax near '06'.", 4612) > > or can i use the ? instead of %s can you give me example since there > is > none in egenix manual for mxODBC. What am i doing wrong. > Also should always use auto_commit while using mxODBC You should instead let 'execute' do the parameter insertion for you, viz: cursor.execute ( "INSERT INTO rss_feed_items(item_date,item_title,item_author,item_permalink,item_desc ription) VALUES(%s,%s,%s,%s,%s)", (new_item_date, new_item_titme, new_item_author, new_item_permalink, new_description) ) This is because, while it LOOKS LIKE that execute is doing python-style %-formatting, it isn't really. The database connector knows what format each of the data types needs to be in, use it :) -- ("`-/")_.-'"``-._ Chris Cogdon . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL From kshahzadbutt at gmail.com Wed Oct 13 16:23:55 2004 From: kshahzadbutt at gmail.com (Khawaja-Shahzad Butt) Date: Wed Oct 13 16:24:01 2004 Subject: [DB-SIG] Problem with mxODBC, please reply Message-ID: Hello Mr. Guido, Since you are the father of python. I just need this clarification. I am not sure what syntax/parameter marker to use for mx.ODBC insert statement. The following works but it's not optimal way to insert: It gives weird exceptions. (just the insert statement). q = "insert into rss_fee feed_title,feed_url,feed_description,feed_rss_version,feed_status)\ values('%s','%s','%s','%s','%s')" % (feedtitle,feedurl,feeddescription,feed_version,feed_status) q=q.encode("utf-8"); c.execute(q) this is another insert statement but a different one: c.execute ( "INSERT INTO rss_feed_items(item_date,item_title,item_author,item_permalink,item_description)\ VALUES(%s,%s,%s,%s,%s)",(item_dmodified, feed_item_title,item_author, feed_item_link,feed_item_feeddescription) ) I get this exception: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\Pythonwin\pywin\framework\scriptutils.py", line 310, in RunScript exec codeObject in __main__.__dict__ File "C:\feedparser-3.3\feedparser\test.py", line 550, in ? info_extract(data,url); File "C:\feedparser-3.3\feedparser\test.py", line 41, in info_extract rss_20extraction(result,url) File "C:\feedparser-3.3\feedparser\test.py", line 312, in rss_20extraction dbinsertfeeditem(feed_item_title,feed_item_link,item_author,feed_item_feeddescription,item_dmodified) File "C:\feedparser-3.3\feedparser\test.py", line 415, in dbinsertfeeditem c.execute ( "INSERT INTO rss_feed_items(item_date,item_title,item_author,item_permalink,item_description)\ InterfaceError: number of parameters in tuple 0: expected 0, found 5 Mark hammond's book on python win32 book doesn't go into much depth about mxODBC. Although steve holden's book has good concepts but lack a lot of examples . I looked through DB-API and mxODBC specs but nothing talks about insert statement and also should i autocommit or not. I am using winxp and activestate win python as IDE, SQL server 2000 as back db. Please reply,. Thank you for you time. I would be grateful Regards Shahzad From kshahzadbutt at gmail.com Wed Oct 13 17:02:15 2004 From: kshahzadbutt at gmail.com (Khawaja-Shahzad Butt) Date: Wed Oct 13 17:02:18 2004 Subject: [DB-SIG] Problems with mxODBC insert statement..Please help Message-ID: Hi, I am using mxODBC as interface between python and MS SQL Server. I am using pythonwin. When i try to run following SQL query c.execute ( 'insert into rss_feed_items(item_date,item_title,item_author,item_permalink,item_description)\ VALUES(?,?,?,?,?)',(item_dmodified, feed_item_title,item_author, feed_item_link,feed_item_feeddescription) ) I get this error: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\Pythonwin\pywin\framework\scriptutils.py", line 310, in RunScript exec codeObject in __main__.__dict__ File "C:\feedparser-3.3\feedparser\test.py", line 548, in ? print data; File "C:\feedparser-3.3\feedparser\test.py", line 41, in info_extract rss_20extraction(result,url) File "C:\feedparser-3.3\feedparser\test.py", line 312, in rss_20extraction dbinsertfeeditem(feed_item_title,feed_item_link,item_author,feed_item_feeddescription,item_dmodified) File "C:\feedparser-3.3\feedparser\test.py", line 413, in dbinsertfeeditem ProgrammingError: ('37000', 0, '[Microsoft][ODBC SQL Server Driver]Syntax error or access violation', 4504) Can you tell me the correct way to use insert statement. An example will help a lot. Also should i have to use auto commit with mxODBC or not. Regards Shahzad From dyoo at hkn.eecs.berkeley.edu Thu Oct 14 21:29:08 2004 From: dyoo at hkn.eecs.berkeley.edu (Danny Yoo) Date: Thu Oct 14 21:29:16 2004 Subject: [DB-SIG] Re: [Tutor] Problem with mxODBC insert statement In-Reply-To: <416C4BF3.8010709@noos.fr> Message-ID: > Khawaja-Shahzad Butt wrote: > > > I don't know how to use SQL which way for mxODBC and python. I used > > this statement and got this error. > > > >q= "INSERT INTO > >rss_feed_items(item_date,item_title,item_author,item_permalink, > > item_description) > > VALUES(%s)"%(item_dmodified); Hello, What's the value of item_dmodified here? The SQL query that you're generating will probably need correction, as there needs to be as many values as there are columns in the SQL insertion statement. I expected to see something like: ### q = """INSERT INTO rss_feed_items( item_date, item_title, item_author, item_permalink, item_description) VALUES( ?, ?, ?, ?, ?)""" ### > >or can i use the ? instead of %s can you give me example since there is > >none in egenix manual for mxODBC. What am i doing wrong. Also should > >always use auto_commit while using mxODBC Let me check the mxODBC manual... ok, here's what they say about parameters: """ execute(operation[,parameters]) Prepare and execute a database operation (query or command). Parameters must be provided as sequence and will be bound to variables in the operation. Variables are specified using the ODBC variable placeholder '?', e.g. 'SELECT name,id FROM table WHERE amount > ? AND amount < ?' (also see the module attribute paramstyle) and get bound in the order they appear in the SQL statement from left to right. A reference to the operation will be retained by the cursor. If the same operation object is passed in again, then the cursor will optimize its behavior by reusing the previously prepared statement. This is most effective for algorithms where the same operation is used, but different parameters are bound to it (many times). """ (http://www.egenix.com/files/python/mxODBC.html) So yes, you can use "?" parameter syntax. For example: ### query = "select * from person where age = ? or grade > ?" cursor = conn.cursor() cursor.execute(query, 25, 60) ### And in fact, you should always use parameter "prepared statements" in SQL unless you have an overwhelming reason not too. There are a lot of potential problems that you can run into if you try to do the string interpolation yourself, so I'd recommend letting the mxODBC driver handle interpolation for you. Good luck! From kshahzadbutt at gmail.com Thu Oct 14 21:53:17 2004 From: kshahzadbutt at gmail.com (Khawaja-Shahzad Butt) Date: Thu Oct 14 21:53:21 2004 Subject: [DB-SIG] mxODBC insert error. Reply Message-ID: Hi, When i try to insert into MS SQL server using mxODBC. python gives me this error: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\Pythonwin\pywin\framework\scriptutils.py", line 310, in RunScript exec codeObject in __main__.__dict__ File "C:\feedparser-3.3\feedparser\test.py", line 559, in ? File "C:\feedparser-3.3\feedparser\test.py", line 41, in info_extract rss_20extraction(result,url) File "C:\feedparser-3.3\feedparser\test.py", line 312, in rss_20extraction dbinsertfeeditem(feed_item_title,feed_item_link,item_author,feed_item_feeddescription,item_dmodified) File "C:\feedparser-3.3\feedparser\test.py", line 417, in dbinsertfeeditem DataError: ('22005', 0, '[Microsoft][ODBC SQL Server Driver]Invalid character value for cast specification', 4579) Here is my insert statement: q="""INSERT INTO rss_feed_items( item_date, item_title, item_author, item_permalink, item_description) VALUES( ?, ?, ?, ?, ?)""" c.execute(q,(item_dmodified,feed_item_title,item_author,feed_item_link,feed_item_feeddescription)) Could anyone tell me what seems to be wrong. Please reply. Thank you, Regards Shahzad From msanchez at grupoburke.com Thu Oct 14 22:07:16 2004 From: msanchez at grupoburke.com (Marcos =?ISO-8859-1?Q?S=E1nchez?= Provencio) Date: Thu Oct 14 22:07:59 2004 Subject: [DB-SIG] mxODBC insert error. Reply In-Reply-To: References: Message-ID: <1097784435.4206.5.camel@renata.macondo.pri> Please tell us what the values of the parameters are and how the table columns are defined. El jue, 14-10-2004 a las 21:53, Khawaja-Shahzad Butt escribi?: > Hi, > When i try to insert into MS SQL server using mxODBC. python gives me > this error: > > Traceback (most recent call last): > File "C:\Python23\Lib\site-packages\Pythonwin\pywin\framework\scriptutils.py", > line 310, in RunScript > exec codeObject in __main__.__dict__ > File "C:\feedparser-3.3\feedparser\test.py", line 559, in ? > File "C:\feedparser-3.3\feedparser\test.py", line 41, in info_extract > rss_20extraction(result,url) > File "C:\feedparser-3.3\feedparser\test.py", line 312, in rss_20extraction > dbinsertfeeditem(feed_item_title,feed_item_link,item_author,feed_item_feeddescription,item_dmodified) > File "C:\feedparser-3.3\feedparser\test.py", line 417, in dbinsertfeeditem > > DataError: ('22005', 0, '[Microsoft][ODBC SQL Server Driver]Invalid > character value for cast specification', 4579) > > > > Here is my insert statement: > > q="""INSERT INTO rss_feed_items( > item_date, > item_title, > item_author, > item_permalink, > item_description) > VALUES( > ?, ?, ?, ?, ?)""" > > c.execute(q,(item_dmodified,feed_item_title,item_author,feed_item_link,feed_item_feeddescription)) > > Could anyone tell me what seems to be wrong. Please reply. > > Thank you, > Regards > Shahzad > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig From kshahzadbutt at gmail.com Thu Oct 14 22:13:10 2004 From: kshahzadbutt at gmail.com (Khawaja-Shahzad Butt) Date: Thu Oct 14 22:13:13 2004 Subject: [DB-SIG] mxODBC insert error. Reply In-Reply-To: <1097784435.4206.5.camel@renata.macondo.pri> References: <1097784435.4206.5.camel@renata.macondo.pri> Message-ID: All these Values are strings. On Thu, 14 Oct 2004 22:07:16 +0200, Marcos S?nchez Provencio wrote: > Please tell us what the values of the parameters are and how the table > columns are defined. > > El jue, 14-10-2004 a las 21:53, Khawaja-Shahzad Butt escribi?: > > > > Hi, > > When i try to insert into MS SQL server using mxODBC. python gives me > > this error: > > > > Traceback (most recent call last): > > File "C:\Python23\Lib\site-packages\Pythonwin\pywin\framework\scriptutils.py", > > line 310, in RunScript > > exec codeObject in __main__.__dict__ > > File "C:\feedparser-3.3\feedparser\test.py", line 559, in ? > > File "C:\feedparser-3.3\feedparser\test.py", line 41, in info_extract > > rss_20extraction(result,url) > > File "C:\feedparser-3.3\feedparser\test.py", line 312, in rss_20extraction > > dbinsertfeeditem(feed_item_title,feed_item_link,item_author,feed_item_feeddescription,item_dmodified) > > File "C:\feedparser-3.3\feedparser\test.py", line 417, in dbinsertfeeditem > > > > DataError: ('22005', 0, '[Microsoft][ODBC SQL Server Driver]Invalid > > character value for cast specification', 4579) > > > > > > > > Here is my insert statement: > > > > q="""INSERT INTO rss_feed_items( > > item_date, > > item_title, > > item_author, > > item_permalink, > > item_description) > > VALUES( > > ?, ?, ?, ?, ?)""" > > > > c.execute(q,(item_dmodified,feed_item_title,item_author,feed_item_link,feed_item_feeddescription)) > > > > Could anyone tell me what seems to be wrong. Please reply. > > > > Thank you, > > Regards > > Shahzad > > _______________________________________________ > > DB-SIG maillist - DB-SIG@python.org > > http://mail.python.org/mailman/listinfo/db-sig > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig > -- ----------------------------------------------- Shahzad Student Programmer Iowa State University Extension http://www.extension.iastate.edu/mt/shahzad/ From chris at cogdon.org Thu Oct 14 23:03:32 2004 From: chris at cogdon.org (Chris Cogdon) Date: Thu Oct 14 23:03:52 2004 Subject: [DB-SIG] mxODBC insert error. Reply In-Reply-To: References: <1097784435.4206.5.camel@renata.macondo.pri> Message-ID: <81B52A6E-1E24-11D9-B38E-000A95E3823E@cogdon.org> On Oct 14, 2004, at 13:13, Khawaja-Shahzad Butt wrote: > All these Values are strings. Just before you do the 'execute', can you put THIS statement: print (item_dmodified,feed_item_title,item_author,feed_item_link,feed_item_fee ddescription) Being in a tuple, this will case a repr of of the object to be sent. We think it likely that your strings have got non-ascii characters in them, and the database is barfing on them. I'm sure the database CAN accept non-ascii characters... but... it needs to be in the 'right' character set. -- ("`-/")_.-'"``-._ Chris Cogdon . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL From dhelm at wcsoftware.com Tue Oct 12 06:23:57 2004 From: dhelm at wcsoftware.com (Doug Helm) Date: Fri Oct 15 00:27:58 2004 Subject: [DB-SIG] What To Import??? Message-ID: <000801c4b013$4a5d4430$6601a8c0@Doug> As great as Python is, there just isn't that much information on accessing relational databases. That's a shocker. What module do I import from the standard Python for Windows install in order to work with common relational databases? I've tried many different things (and a variety of case variations, but I'm showing lower case)... import odbc import dbapi import db import anydb import oracledb import accessdb import msaccessdb import mysqldb etc., etc., etc. I have the standard Python for Windows installed (2.4.3a). Once I get the proper module installed, everything seems pretty familiar (i.e. I know what to do with connection and cursor objects). But, what do I import in order to gain access to those fine objects??? Confused (and surprised that there isn't a ton of information on this subject)... Thanks. Doug Helm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20041011/2f9d2f21/attachment.html From my.mailing.lists at noos.fr Tue Oct 12 23:26:11 2004 From: my.mailing.lists at noos.fr (nik) Date: Fri Oct 15 00:29:41 2004 Subject: [DB-SIG] Re: [Tutor] Problem with mxODBC insert statement In-Reply-To: References: Message-ID: <416C4BF3.8010709@noos.fr> This is only a guess, but if (item_dmodified) is a tuple, shouldn't it be (item_dmodified,) for a tuple with a single item (ie missing the comma). nik Khawaja-Shahzad Butt wrote: >Hello, > > I don't know how to use SQL which way for mxODBC and >python. I used this statement and got this error. > >q= "INSERT INTO >rss_feed_items(item_date,item_title,item_author,item_permalink,item_description)\ > VALUES(%s)"%(item_dmodified); > >MS SQL server 2000 gave me this error for above query statement: > >ProgrammingError: ('37000', 170, "[Microsoft][ODBC SQL Server >Driver][SQL Server]Line 1: Incorrect syntax near '06'.", 4612) > >or can i use the ? instead of %s can you give me example since there is >none in egenix manual for mxODBC. What am i doing wrong. >Also should always use auto_commit while using mxODBC > >Please reply. >Thank you, >Regards >Shahzad >_______________________________________________ >Tutor maillist - Tutor@python.org >http://mail.python.org/mailman/listinfo/tutor > > > > From TKeating at ea.com Fri Oct 8 19:02:38 2004 From: TKeating at ea.com (Keating, Tim) Date: Fri Oct 15 00:32:13 2004 Subject: [DB-SIG] Re: [Python-Dev] Toward Python's future article Message-ID: <25BCE2B1149CDA4E9758CC08E70A20A9FD6564@eahq-mb1> Chris Cogsden wrote: > In my humble opinion, and with all the proper deference to those that > have written excellent and useful code, I disagree (and have always, in > the past on this list) with the above two statements. > > Giving the module author a choice in implementation is great, but given > them a choice in the data-type being returned just pushes the problem > of dealing with differing data types onto the application writer. > > Making things 'easy for the module writer' is well and good... it gets > a useful module out there quicker and with fewer bugs, but this makes > it harder for the application writer, and I don't think that should be > the focus. After all, the 'hard job' of writing the module is only done > once (or, really, just a few times, for each database type and each > person that decides to put the effort in to create a variation), but > the job of writing applications is done over and over. > > I think it SHOULD BE the job of the module writer (whether it's a DB > interface, or an interface to the operating system) to deal with all > the vagaries of the underlying layers and present a consistent (as far > as possible) interface to the application writer. I appreciate that > this is much harder with something like a DB interface, but for > something as simple as date/time return types, it should be mandated. > > Otherwise, it's like saying "the module writer has the choice of > returning integer values as a int, long, or a string, and it's up to > the application writer to deal with it". Well said. This was my reaction, as well. Probably because I'm one of those "application writers" people keep talking about. TK From chris at cogdon.org Fri Oct 15 01:09:22 2004 From: chris at cogdon.org (Chris Cogdon) Date: Fri Oct 15 01:09:29 2004 Subject: [DB-SIG] What To Import??? In-Reply-To: <000801c4b013$4a5d4430$6601a8c0@Doug> References: <000801c4b013$4a5d4430$6601a8c0@Doug> Message-ID: <15C961E8-1E36-11D9-B38E-000A95E3823E@cogdon.org> On Oct 11, 2004, at 21:23, Doug Helm wrote: > Once I get the proper module installed, everything seems pretty > familiar (i.e. I know what to do with connection and cursor objects).? > But, what do I import in order to gain access to those fine objects??? > ? > Confused (and surprised that there isn't a ton of information on this > subject)... The name of the module to import will depend on the particular package that you've installed. Refer to the package's documentation. I don't use windows myself, but I do know that one of the packages uses a module called mxODBC. Eg: import mxODBC db = mxODBC.connect ( .... ) -- ("`-/")_.-'"``-._ Chris Cogdon . . `; -._ )-;-,_`) (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' ((,.-' ((,/ fL From peter at monicol.co.uk Fri Oct 15 11:36:19 2004 From: peter at monicol.co.uk (Peter Mott) Date: Fri Oct 15 11:36:21 2004 Subject: [DB-SIG] What To Import??? In-Reply-To: <15C961E8-1E36-11D9-B38E-000A95E3823E@cogdon.org> Message-ID: mxODBC is at www.egenix.com. It is commercial I think. There is an old ODBC module part of the win32 extensions that Mark Hammond made. It is available from the Python site along with the language downloads. I don't know of any other ODBC interfaces. Peter > -----Original Message----- > From: db-sig-bounces@python.org [mailto:db-sig-bounces@python.org] On > Behalf Of Chris Cogdon > Sent: 15 October 2004 00:09 > To: Doug Helm > Cc: db-sig@python.org > Subject: Re: [DB-SIG] What To Import??? > > > On Oct 11, 2004, at 21:23, Doug Helm wrote: > > > Once I get the proper module installed, everything seems pretty > > familiar (i.e. I know what to do with connection and cursor objects). > > But, what do I import in order to gain access to those fine objects??? > > > > Confused (and surprised that there isn't a ton of information on this > > subject)... > > The name of the module to import will depend on the particular package > that you've installed. Refer to the package's documentation. > > I don't use windows myself, but I do know that one of the packages uses > a module called mxODBC. Eg: > > import mxODBC > > db = mxODBC.connect ( .... ) > > > -- > ("`-/")_.-'"``-._ Chris Cogdon > . . `; -._ )-;-,_`) > (v_,)' _ )`-.\ ``-' > _.- _..-_/ / ((.' > ((,.-' ((,/ fL > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig From wilk-ml at flibuste.net Fri Oct 15 11:51:20 2004 From: wilk-ml at flibuste.net (William Dode) Date: Fri Oct 15 11:51:22 2004 Subject: [DB-SIG] What To Import??? In-Reply-To: (Peter Mott's message of "Fri, 15 Oct 2004 10:36:19 +0100") References: Message-ID: <87lle848dj.fsf@chat.blakie.riol> "Peter Mott" writes: > mxODBC is at www.egenix.com. It is commercial I think. There is an old ODBC > module part of the win32 extensions that Mark Hammond made. It is available > from the Python site along with the language downloads. I don't know of any > other ODBC interfaces. There is also http://adodbapi.sf.net, it's free (lgpl), you can connect to odbc or directly to ms databases. Maybe it could be include in win32 extensions ? I use it in production, it works very well. -- William - http://flibuste.net From mal at egenix.com Fri Oct 15 12:29:20 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Oct 15 12:29:23 2004 Subject: [DB-SIG] What To Import??? In-Reply-To: References: Message-ID: <416FA680.7070303@egenix.com> Peter Mott wrote: > mxODBC is at www.egenix.com. It is commercial I think. There is an old ODBC > module part of the win32 extensions that Mark Hammond made. It is available > from the Python site along with the language downloads. I don't know of any > other ODBC interfaces. Here's a quick-start guide for installing mxODBC on Windows: 1. visit: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Download-mxBASE and download the egenix-mx-base package for your Python version, e.g. http://www.egenix.com/files/python/egenix-mx-base-2.0.5.win32-py2.3.exe 2. scroll down to: http://www.egenix.com/files/python/eGenix-mx-Extensions.html#Download-mxCOMMERCIAL and download the egenix-mx-commercial package for your Python version, e.g. http://www.egenix.com/files/python/egenix-mx-commercial-2.0.6.win32-py2.3.exe 3. Install the two packages by clicking on the EXEs (first the egenix-mx-base package, then the egenix-mx-commercial package). An installer will start that will guide you through the rest of the installation. 4. Open a Python command line, e.g IDLE 5. Test the installation by entering the following commands at the prompt: >>> from mx.ODBC.Windows import DataSources >>> print DataSources() This should give you a list of available ODBC data sources registered with your Windows ODBC manager. The full mxODBC documentation is available at: http://www.egenix.com/files/python/mxODBC.html Please note that mxODBC is free to use for non-commercial user only. Hope that helps, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 15 2004) >>> 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 wnvcole at peppermillcas.com Fri Oct 15 17:27:49 2004 From: wnvcole at peppermillcas.com (Vernon Cole) Date: Fri Oct 15 17:27:55 2004 Subject: [DB-SIG] What To Import??? Message-ID: <1DE30EB3ECE266409FDE6E7032F178C413982E@pcimail1s.peppermillcas.com> Peter: mxODBC is a commercial product, which is why I don't use it. The ODBC module which is included in win32all is no longer maintained and has a few problems. ADO is Microsoft's latest data access method -- they invented ODBC, but I guess it got too popular. ;-) ADO is a superset of ODBC and can use ODBC as one of its data sources. see http://www.connectionstrings.com The ADO module is free to all and works GREAT. ------------ Vernon See below: v v v v vv v v v v Project ------- adodbapi A Python DB-API 2.0 module that makes it easy to use Microsoft ADO for connecting with databases and other data sources. Home page: Features: * 100% DB-API 2.0 compliant. * Includes pyunit testcases that describes how to use the module. * Fully implemented in Python. * Licensed under the LGPL license, which means that it can be used freely even in commercial programs subject to certain restrictions. * Supports eGenix mxDateTime, Python 2.3 datetime module and Python time module. Prerequisites: * Python 1.5.2 or higher. * Mark Hammond's win32all python for windows extensions. [....] -----Original Message----- From: db-sig-bounces+wnvcole=peppermillcas.com@python.org [mailto:db-sig-bounces+wnvcole=peppermillcas.com@python.org]On Behalf Of M.-A. Lemburg Sent: Friday, October 15, 2004 4:29 AM To: Peter Mott Cc: db-sig@python.org Subject: Re: [DB-SIG] What To Import??? Peter Mott wrote: > mxODBC is at www.egenix.com. It is commercial I think. There is an old ODBC > module part of the win32 extensions that Mark Hammond made. It is available > from the Python site along with the language downloads. I don't know of any > other ODBC interfaces. From James.Briggs at unisuper.com.au Mon Oct 18 01:32:23 2004 From: James.Briggs at unisuper.com.au (James Briggs) Date: Mon Oct 18 01:33:32 2004 Subject: [DB-SIG] What To Import??? Message-ID: I use both mxODBC and adodbapi to connect to various databases. here is my 2 cents worth: adodpapi - its free - it returns Python datetime objects - doesn't require an ODBC DSN to be defined on the machine for the DB to be connected too - but, generates difficult to interpret errors. therefore, perfect for distributing with working windows applications around where I work --- mx.ODBC - sure its commercial, but hardly expensive. - generates nicer error messages - has access to standard ODBC table() and column() definition stuff - can switch autocommit on/off - but, returns the mx.DateTime datatype - requires DSN to be define on the PC where it is used to connect. therefore, I often prefer to use mx.ODBC for some development and connecting to obscure database like DB2 on AS400. James Briggs "This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or UniSuper Limited (ABN 54 006 027 121) or its subsidiaries. UniSuper Management Pty Ltd (AFSL No: 235907) From mal at egenix.com Mon Oct 18 03:25:36 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Oct 18 10:28:30 2004 Subject: [DB-SIG] What To Import??? In-Reply-To: References: Message-ID: <41731B90.9090908@egenix.com> James Briggs wrote: > > I use both mxODBC and adodbapi to connect to various databases. > > here is my 2 cents worth: > > adodpapi > - its free > - it returns Python datetime objects > - doesn't require an ODBC DSN to be defined on the machine for the DB > to be connected too > - but, generates difficult to interpret errors. > > therefore, perfect for distributing with working windows applications > around where I work > > --- > > mx.ODBC > - sure its commercial, but hardly expensive. > - generates nicer error messages > - has access to standard ODBC table() and column() definition stuff > - can switch autocommit on/off > - but, returns the mx.DateTime datatype The next release of mxODBC will offer Python datetime objects as configurable alternative date/time object for Python 2.4 and above, along with mxDateTime object, tuples and Unix ticks (the current list of supported date/time types). > - requires DSN to be define on the PC where it is used to connect. This not correct: you can define the data source in the connection string if you know what the name of ODBC driver is and without having to configure the data source on the PC running that application: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcconnecting_directly_to_drivers.asp Example: db = mx.ODBC.Windows("DRIVER={SQL Server};SERVER=hrserver;UID=Smith;PWD=Sesame") cursor = db.cursor() ... This example is for the MS SQL Server. More information is available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbcsql/od_odbc_d_4x4k.asp > therefore, I often prefer to use mx.ODBC for some development and > connecting to obscure database like DB2 on AS400. There's also another argument for mxODBC which you haven't mentioned: - works on Windows, Linux, AIX, Solaris, *BSD and most other *nix platforms; using the same interface on all these platforms -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 18 2004) >>> 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 wilk-ml at flibuste.net Mon Oct 18 11:08:21 2004 From: wilk-ml at flibuste.net (William Dode) Date: Mon Oct 18 11:08:23 2004 Subject: [DB-SIG] What To Import??? In-Reply-To: <41731B90.9090908@egenix.com> (mal@egenix.com's message of "Mon, 18 Oct 2004 03:25:36 +0200") References: <41731B90.9090908@egenix.com> Message-ID: <87oej01ji2.fsf@chat.blakie.riol> >> mx.ODBC >> - sure its commercial, but hardly expensive. The licence says "non-commercial use is free of charge". For example, if i make a software with an opensource licence (GPL for example), and i sell services around my software, can i use mx.odbc without paying ? It'll be more clear if it was two licences, one for commercial product and one for gpl or open-sources product. Like qt. -- William - http://flibuste.net From mal at egenix.com Mon Oct 18 04:20:29 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Oct 18 11:23:22 2004 Subject: [DB-SIG] What To Import??? In-Reply-To: <87oej01ji2.fsf@chat.blakie.riol> References: <41731B90.9090908@egenix.com> <87oej01ji2.fsf@chat.blakie.riol> Message-ID: <4173286D.5000807@egenix.com> William Dode wrote: >>>mx.ODBC >>> - sure its commercial, but hardly expensive. > > The licence says "non-commercial use is free of charge". > > For example, if i make a software with an opensource licence (GPL for > example), and i sell services around my software, can i use mx.odbc > without paying ? > > It'll be more clear if it was two licences, one for commercial product > and one for gpl or open-sources product. Like qt. This is not the right place to discuss licensing issues. I'll answer your request in private mail. For questions about mxODBC licensing, pleae write to licenses@egenix.com. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 18 2004) >>> 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 kshahzadbutt at gmail.com Mon Oct 18 14:37:35 2004 From: kshahzadbutt at gmail.com (Khawaja-Shahzad Butt) Date: Mon Oct 18 14:37:38 2004 Subject: [DB-SIG] DataError: ('22005', 0, '[Microsoft][ODBC SQL Server Driver] Message-ID: Hi, When i am connecting to SQL Server through mxODBC as system DSN. db = mx.ODBC.Windows.DriverConnect('DSN=zoe;UID=test;PWD=temp') c = db.cursor() When i use this SQL query, it gives me this error q="""INSERT INTO rss_feed_items( item_date, item_title, item_author, item_permalink, item_description) VALUES( ?, ?, ?, ?, ?)""" c.execute(q,(item_dmodified,feed_item_title,item_author,feed_item_link,feed_item_feeddescription),) db.commit() I get this weird error. raceback (most recent call last): File "C:\Python23\Lib\site-packages\Pythonwin\pywin\framework\scriptutils.py", line 310, in RunScript exec codeObject in __main__.__dict__ File "C:\feedparser-3.3\feedparser\test.py", line 561, in ? info_extract(data,url); File "C:\feedparser-3.3\feedparser\test.py", line 41, in info_extract rss_20extraction(result,url) File "C:\feedparser-3.3\feedparser\test.py", line 312, in rss_20extraction dbinsertfeeditem(feed_item_title,feed_item_link,item_author,feed_item_feeddescription,item_dmodified) File "C:\feedparser-3.3\feedparser\test.py", line 417, in dbinsertfeeditem c.execute(q,(item_dmodified,feed_item_title,item_author,feed_item_link,feed_item_feeddescription),) DataError: ('22005', 0, '[Microsoft][ODBC SQL Server Driver]Invalid character value for cast specification', 4579) I know the query works if use it like a string but all the fields in the table are not strings. e.g. q = "insert into rss_feed_items(item_date,item_title,item_author,item_permalink,item_description)\ values('%s','%s','%s','%s','%s')" % (item_dmodified,feed_item_title,item_author,feed_item_link,feed_item_feeddescription) Then i have encoded into utf-8 otherwise pythong gives error that the query string should be string. something like that. q=q.encode("utf-8"); db.commit() So what should i do. I have looked around and didn't see any solution for this problem.Please help. I would be grateful. Regards Shahzad From marcos at burke.ath.cx Mon Oct 18 15:59:47 2004 From: marcos at burke.ath.cx (=?ISO-8859-1?Q?Marcos_S=E1nchez_Provencio?=) Date: Mon Oct 18 16:02:29 2004 Subject: [DB-SIG] DataError: ('22005', 0, '[Microsoft][ODBC SQL Server Driver] In-Reply-To: References: Message-ID: <4173CC53.9080505@burke.ath.cx> You may try to convert each of the strings you want to insert into UTF8 before using them in the query. For example, if the string that contains non-ascii chars is feed_item_feeddescription: feed_item_feeddescription_utf8=feed_item_feeddescription.encode('utf8') c.execute(q,(item_dmodified,feed_item_title,item_author,feed_item_link,feed_item_feeddescription_utf8),) Khawaja-Shahzad Butt escribi?: >Hi, > When i am connecting to SQL Server through mxODBC as system DSN. > >db = mx.ODBC.Windows.DriverConnect('DSN=zoe;UID=test;PWD=temp') >c = db.cursor() >When i use this SQL query, it gives me this error > > q="""INSERT INTO rss_feed_items( > item_date, > item_title, > item_author, > item_permalink, > item_description) > VALUES( > ?, ?, ?, ?, ?)""" >c.execute(q,(item_dmodified,feed_item_title,item_author,feed_item_link,feed_item_feeddescription),) > > db.commit() > >I get this weird error. > >raceback (most recent call last): > File "C:\Python23\Lib\site-packages\Pythonwin\pywin\framework\scriptutils.py", >line 310, in RunScript > exec codeObject in __main__.__dict__ > File "C:\feedparser-3.3\feedparser\test.py", line 561, in ? > info_extract(data,url); > File "C:\feedparser-3.3\feedparser\test.py", line 41, in info_extract > rss_20extraction(result,url) > File "C:\feedparser-3.3\feedparser\test.py", line 312, in rss_20extraction > dbinsertfeeditem(feed_item_title,feed_item_link,item_author,feed_item_feeddescription,item_dmodified) > File "C:\feedparser-3.3\feedparser\test.py", line 417, in dbinsertfeeditem > c.execute(q,(item_dmodified,feed_item_title,item_author,feed_item_link,feed_item_feeddescription),) >DataError: ('22005', 0, '[Microsoft][ODBC SQL Server Driver]Invalid >character value for cast specification', 4579) > > >I know the query works if use it like a string but all the fields in >the table are not strings. e.g. > > q = "insert into >rss_feed_items(item_date,item_title,item_author,item_permalink,item_description)\ > values('%s','%s','%s','%s','%s')" % >(item_dmodified,feed_item_title,item_author,feed_item_link,feed_item_feeddescription) > >Then i have encoded into utf-8 otherwise pythong gives error that the >query string should be string. something like that. > >q=q.encode("utf-8"); > > db.commit() > >So what should i do. I have looked around and didn't see any solution >for this problem.Please help. I would be grateful. >Regards >Shahzad > > From kshahzadbutt at gmail.com Mon Oct 18 16:28:32 2004 From: kshahzadbutt at gmail.com (Khawaja-Shahzad Butt) Date: Mon Oct 18 16:28:34 2004 Subject: [DB-SIG] DataError: ('22005', 0, '[Microsoft][ODBC SQL Server Driver]Invalid character value for cast specification', 4579) Message-ID: Hello all, my code looks like this: db = mx.ODBC.Windows.DriverConnect('DSN=zoe;UID=test;PWD=temp') c = db.cursor() dq= "delete from rss_feed_items" c.execute(dq) feed_item_feeddescription_utf8=feed_item_feeddescription.encode('utf8'); feed_item_title=feed_item_title.encode('utf8'); feed_item_link=feed_item_link.encode('utf8'); item_author=item_author.encode('utf8'); item_dmodified=item_dmodified.encode('utf8'); q="""INSERT INTO rss_feed_items( item_date, item_title, item_author, item_permalink, item_description) VALUES( ?, ?, ?, ?, ?)""" . c.execute(q,(item_dmodified,feed_item_title,item_author,feed_item_link,feed_item_feeddescription_utf8),) db.commit() c.close() db.close() I get this error: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\Pythonwin\pywin\framework\scriptutils.py", line 310, in RunScript exec codeObject in __main__.__dict__ File "C:\feedparser-3.3\feedparser\test.py", line 573, in ? File "C:\feedparser-3.3\feedparser\test.py", line 41, in info_extract rss_20extraction(result,url) File "C:\feedparser-3.3\feedparser\test.py", line 312, in rss_20extraction dbinsertfeeditem(feed_item_title,feed_item_link,item_author,feed_item_feeddescription,item_dmodified) File "C:\feedparser-3.3\feedparser\test.py", line 432, in dbinsertfeeditem ## c.execute("insert into rss_feed_items (item_date,item_title,item_author,item_permalink,item_description)\ DataError: ('22005', 0, '[Microsoft][ODBC SQL Server Driver]Invalid character value for cast specification', 4579) I am using connection to SQL servers as system DSN. python win and mxODBC. I am unable to figure what's the problem. Please reply Thank you From randall at tnr.cc Tue Oct 19 06:46:29 2004 From: randall at tnr.cc (Randall Smith) Date: Tue Oct 19 06:46:42 2004 Subject: [DB-SIG] API test available? Message-ID: <41749C25.1040803@tnr.cc> I've been using and debugging the Pydal (dal) module and am wandering if there is a test available to check the API. I've written some tests that connect to various databases (MySQL, PostgreSQL, Oracle) to test the module, but they are not comprehensive. I do not have a problem with writing tests, but I do not want to reinvent the wheel. Especially if a mature solution exists. Any suggestions welcome. Randall From mal at egenix.com Tue Oct 19 10:18:49 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Oct 19 10:18:52 2004 Subject: [DB-SIG] API test available? In-Reply-To: <41749C25.1040803@tnr.cc> References: <41749C25.1040803@tnr.cc> Message-ID: <4174CDE9.90803@egenix.com> Randall Smith wrote: > I've been using and debugging the Pydal (dal) module and am wandering if > there is a test available to check the API. I've written some tests > that connect to various databases (MySQL, PostgreSQL, Oracle) to test > the module, but they are not comprehensive. I do not have a problem > with writing tests, but I do not want to reinvent the wheel. Especially > if a mature solution exists. Any suggestions welcome. Stuart Bishop has written a DB API 2.0 compliance test which you might want to take a look at: http://zen.freezope.org/Software/DBAPI20TestSuite/ mxODBC comes with a test script (in mx/ODBC/Misc), but it's more geared to test database capabilities - testing mxODBC's data type handling is a nice side-effect :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 19 2004) >>> 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 kshahzadbutt at gmail.com Tue Oct 19 21:33:35 2004 From: kshahzadbutt at gmail.com (Khawaja-Shahzad Butt) Date: Thu Oct 21 02:04:35 2004 Subject: [DB-SIG] Insert Problem solved, one question please reply In-Reply-To: <417564F4.60104@egenix.com> References: <417564F4.60104@egenix.com> Message-ID: Hello Mr. Marc, I configured out the problem with sql insert with mxODBC. I use this statement. areaI = "INSERT INTO rss_feed_items (item_title,item_author,item_permalink,item_description) VALUES (?,?,?,?)" c2 = db.cursor() c2.execute(areaI, (feed_item_title , item_author, feed_item_link, feed_item_feeddescription_utf8)) db.commit() The problem was date and time variable for which i used ? SQL gave error of: item_dmodified if use it in above query. I get this error: DataError: ('22005', 0, '[Microsoft][ODBC SQL Server Driver]Invalid character value for cast specification', 4579) Since i am getting the date and time in raw format from rss file and converting it into string like this: s=item_dmodified zs=email.Utils.mktime_tz(email.Utils.parsedate_tz(s)) item_dmodified = time.strftime('%m-%d-%Y %H:%M', time.localtime(zs)); Tue, 19 Oct 2004 19:27:33 GMT -> 10/19/2004 6:00:00 AM the targe filed item_date in MS SQL server is small date and time. If i do separate query string for item_date it works but it goes into next row not with and i want to insert it 1 single query. I have both mxODBC base and commercial. Please tell me what should i do? Thanks for your help and suggestion. I hope you would help. From shahzad at iastate.edu Wed Oct 20 15:28:24 2004 From: shahzad at iastate.edu (Khawaja Shahzad Sadiq ) Date: Thu Oct 21 02:05:02 2004 Subject: [DB-SIG] Insert Problem solved, one question please reply Message-ID: <2428820910432931@webmail.iastate.edu> Hi , I configured out the problem with sql insert with mxODBC. I use this statement. areaI = "INSERT INTO rss_feed_items (item_title,item_author,item_permalink,item_description) VALUES (?,?,?,?)" c2 = db.cursor() c2.execute(areaI, (feed_item_title , item_author, feed_item_link, feed_item_feeddescription_utf8)) db.commit() The problem was date and time variable for which i used ? SQL gave error of: item_dmodified if use it in above query. I get this error: DataError: ('22005', 0, '[Microsoft][ODBC SQL Server Driver]Invalid character value for cast specification', 4579) Since i am getting the date and time in raw format from rss file and converting it into string like this: s=item_dmodified zs=email.Utils.mktime_tz(email.Utils.parsedate_tz(s)) item_dmodified = time.strftime('%m-%d-%Y %H:%M', time.localtime(zs)); Tue, 19 Oct 2004 19:27:33 GMT -> 10/19/2004 6:00:00 AM the targe filed item_date in MS SQL server is small date and time. If i do separate query string for item_date it works but it goes into next row not with and i want to insert it 1 single query. I have both mxODBC base and commercial. Please tell me what should i do? Thanks for your help and suggestion. I hope you would help. From marcos at burke.ath.cx Thu Oct 21 11:12:20 2004 From: marcos at burke.ath.cx (=?ISO-8859-1?Q?Marcos_S=E1nchez_Provencio?=) Date: Thu Oct 21 11:13:28 2004 Subject: [DB-SIG] Insert Problem solved, one question please reply In-Reply-To: <2428820910432931@webmail.iastate.edu> References: <2428820910432931@webmail.iastate.edu> Message-ID: <41777D74.2050400@burke.ath.cx> I suppose mx.ODBC will deal very well with mx.DateTime parameters... Khawaja Shahzad Sadiq escribi?: >Hi , > I configured out the problem with sql insert >with mxODBC. >I use this statement. >areaI = "INSERT INTO rss_feed_items >(item_title,item_author,item_permalink,item_description) VALUES >(?,?,?,?)" > c2 = db.cursor() > c2.execute(areaI, (feed_item_title , item_author, feed_item_link, >feed_item_feeddescription_utf8)) > db.commit() > >The problem was date and time variable for which i used ? SQL gave error of: >item_dmodified >if use it in above query. I get this error: > >DataError: ('22005', 0, '[Microsoft][ODBC SQL Server Driver]Invalid >character value for cast specification', 4579) > >Since i am getting the date and time in raw format from rss file and >converting it into string like this: > >s=item_dmodified >zs=email.Utils.mktime_tz(email.Utils.parsedate_tz(s)) >item_dmodified = time.strftime('%m-%d-%Y %H:%M', time.localtime(zs)); >Tue, 19 Oct 2004 19:27:33 GMT -> 10/19/2004 6:00:00 AM > >the targe filed item_date in MS SQL server is small date and time. > >If i do separate query string for item_date it works but it goes into >next row not with and i want to insert it 1 single query. I have both >mxODBC base and commercial. > >Please tell me what should i do? Thanks for your help and suggestion. >I hope you would help. > > > From mal at egenix.com Thu Oct 21 11:30:28 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Oct 21 11:30:30 2004 Subject: [DB-SIG] Insert Problem solved, one question please reply In-Reply-To: <41777D74.2050400@burke.ath.cx> References: <2428820910432931@webmail.iastate.edu> <41777D74.2050400@burke.ath.cx> Message-ID: <417781B4.4030204@egenix.com> Marcos S?nchez Provencio wrote: > I suppose mx.ODBC will deal very well with mx.DateTime parameters... Indeed it does :-) mxODBC will take mxDateTime objects, tuples, floats and strings as input for date/time fields. If you choose strings you have to be aware that the database will have to parse the date/time representation your are using. This will often fail in one way or another, even if you stick to ISO date/time formats, so using one of the other possibilities is usually the safer way to go. > Khawaja Shahzad Sadiq escribi?: > >> Hi , >> I configured out the problem with sql insert >> with mxODBC. >> I use this statement. >> areaI = "INSERT INTO rss_feed_items >> (item_title,item_author,item_permalink,item_description) VALUES >> (?,?,?,?)" >> c2 = db.cursor() >> c2.execute(areaI, (feed_item_title , item_author, feed_item_link, >> feed_item_feeddescription_utf8)) >> db.commit() >> >> The problem was date and time variable for which i used ? SQL gave >> error of: >> item_dmodified >> if use it in above query. I get this error: >> >> DataError: ('22005', 0, '[Microsoft][ODBC SQL Server Driver]Invalid >> character value for cast specification', 4579) >> >> Since i am getting the date and time in raw format from rss file and >> converting it into string like this: >> >> s=item_dmodified >> zs=email.Utils.mktime_tz(email.Utils.parsedate_tz(s)) >> item_dmodified = time.strftime('%m-%d-%Y %H:%M', time.localtime(zs)); >> Tue, 19 Oct 2004 19:27:33 GMT -> 10/19/2004 6:00:00 AM >> >> the targe filed item_date in MS SQL server is small date and time. >> >> If i do separate query string for item_date it works but it goes into >> next row not with and i want to insert it 1 single query. I have both >> mxODBC base and commercial. >> >> Please tell me what should i do? Thanks for your help and suggestion. >> I hope you would help. >> >> >> > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 21 2004) >>> 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 ! ::::