From carsten at uniqsys.com Sun Oct 1 16:41:10 2006 From: carsten at uniqsys.com (Carsten Haese) Date: Sun, 1 Oct 2006 10:41:10 -0400 Subject: [DB-SIG] [ANN] InformixDB-2.3 released Message-ID: <20061001143722.M33987@uniqsys.com> I am pleased to announce a new release of InformixDB, the DB-API 2.0 module for connecting to IBM Informix database engines. Changes since version 2.2: - Allow parameter list for executemany() to be arbitrary iterable objects. - .prepare() method and .command attribute for explicitly prepared statements - Python 2.5 compatibility - Bug fixes: * Rare crashes caused by missing error check in DESCRIBE step. * Inconsistent UDT input binding caused SQLCODE -1820 in bulk insert (executemany) if UDT contents went back and forth across 32K size boundary or between null and non-null. * EXECUTE PROCEDURE erroneously attempted to open a results cursor for procedures that don't return results. * Date columns were read incorrectly on 64 bit platforms due to mixup of int4 versus long. Downloads and info at http://informixdb.sourceforge.net Best regards, Carsten Haese From mfrasca at zonnet.nl Tue Oct 3 11:49:11 2006 From: mfrasca at zonnet.nl (Mario Frasca) Date: Tue, 3 Oct 2006 11:49:11 +0200 Subject: [DB-SIG] thoughts about OpenGIS extensions Message-ID: <20061003094911.GA19705@kruiskruid.demon.nl> hallo list, I'm starting to play around with OpenGIS extensions to MySQL and PostgreSQL. well, a bit more than just playing around actually. one thing I'm missing is the ability to handle OpenGIS objects as python OpenGIS objects. right now I'm writing the queries so that I keep in memory (list of) point coordinates. where I'm working I would like to use the GPL library I've been working at since 2002. but I miss a python OpenGIS class hierarchy. actually I don't need that the library provides anything else than a class hierarchy, for the time being I don't need any operations on the OpenGIS objects... but I do need that the python interface modules recognize the OpenGIS data coming from the database as such. is this something I should add as user of the library, be it mysqldb or pgdb? or should I expect the library to provide this data in a specific format? since we have this OpenGIS standard, I would expect that we take care of aknowledging it into python... (there doesn't seem to be much work around about it, at least, not that is being actively developed.) I'll be reading with interest any reactions. MF -- 'free' taken as in free speech, not free beer. Richard Stallman From fog at initd.org Tue Oct 3 11:55:10 2006 From: fog at initd.org (Federico Di Gregorio) Date: Tue, 03 Oct 2006 11:55:10 +0200 Subject: [DB-SIG] thoughts about OpenGIS extensions In-Reply-To: <20061003094911.GA19705@kruiskruid.demon.nl> References: <20061003094911.GA19705@kruiskruid.demon.nl> Message-ID: <1159869310.3796.33.camel@localhost> Il giorno mar, 03/10/2006 alle 11.49 +0200, Mario Frasca ha scritto: > I'm starting to play around with OpenGIS extensions to MySQL and > PostgreSQL. well, a bit more than just playing around actually. > > one thing I'm missing is the ability to handle OpenGIS objects as > python OpenGIS objects. right now I'm writing the queries so that I > keep in memory (list of) point coordinates. > > where I'm working I would like to use the GPL library I've been working > at since 2002. but I miss a python OpenGIS class hierarchy. actually I > don't need that the library provides anything else than a class hierarchy, > for the time being I don't need any operations on the OpenGIS objects... > but I do need that the python interface modules recognize the OpenGIS > data coming from the database as such. > > is this something I should add as user of the library, be it mysqldb or > pgdb? or should I expect the library to provide this data in a specific > format? psycopg supports type adaptation and type-caster registration (yeah, buzz-words) for any Python or PostgreSQL type. That means that you can register adapters (Python->PostgreSQL) and type-casters (PostgreSQL->Python) to convert your OpenGIS objects to PostgreSQL OpenGIS types and vice versa. This feature is used by the GeoTypes module that adds support for all geometrical types to psycopg. See: http://initd.org/tracker/psycopg/wiki/GeoTypes http://initd.org/tracker/psycopg Hope this helps, federico -- Federico Di Gregorio http://people.initd.org/fog Debian GNU/Linux Developer fog at debian.org INIT.D Developer fog at initd.org Beh un bacio, se ben dato, non si rifiuta. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio firmata digitalmente Url : http://mail.python.org/pipermail/db-sig/attachments/20061003/8cd07310/attachment.pgp From mfrasca at zonnet.nl Tue Oct 3 13:17:21 2006 From: mfrasca at zonnet.nl (Mario Frasca) Date: Tue, 3 Oct 2006 13:17:21 +0200 Subject: [DB-SIG] thoughts about OpenGIS extensions In-Reply-To: <1159869310.3796.33.camel@localhost> References: <20061003094911.GA19705@kruiskruid.demon.nl> <1159869310.3796.33.camel@localhost> Message-ID: <20061003111721.GB19864@kruiskruid.demon.nl> On 2006-1003 11:55:10, Federico Di Gregorio wrote: > psycopg supports type adaptation and type-caster registration > (yeah, buzz-words) for any Python or PostgreSQL type. yes, I had forgotten about psycopg2, sorry... :) I can't remember if type adaptation and type-caster registration are a prerogative of psycopg2 or are in general available on all db-api2 modules. > This feature is used by the GeoTypes module that adds support > for all geometrical types to psycopg. See: > http://initd.org/tracker/psycopg/wiki/GeoTypes I just downloaded it. I'm mostly interested in seeing how you manage to translate data from postgresql to the client program. I mean: how you recognize it's gis data and not just any blob... > Hope this helps, I'm sure it does. grazie, ciao, Mario -- [quello che cito] non esprime in alcun modo il mio pensiero personale Papa Ratzinger From fog at initd.org Tue Oct 3 14:39:35 2006 From: fog at initd.org (Federico Di Gregorio) Date: Tue, 03 Oct 2006 14:39:35 +0200 Subject: [DB-SIG] thoughts about OpenGIS extensions In-Reply-To: <20061003111721.GB19864@kruiskruid.demon.nl> References: <20061003094911.GA19705@kruiskruid.demon.nl> <1159869310.3796.33.camel@localhost> <20061003111721.GB19864@kruiskruid.demon.nl> Message-ID: <1159879175.3796.42.camel@localhost> Il giorno mar, 03/10/2006 alle 13.17 +0200, Mario Frasca ha scritto: > I can't remember if type adaptation and type-caster registration are > a prerogative of psycopg2 or are in general available on all db-api2 > modules. They are a prerogative of psycopg but other drivers offer similar methods. > > This feature is used by the GeoTypes module that adds support > > for all geometrical types to psycopg. See: > > http://initd.org/tracker/psycopg/wiki/GeoTypes > > I just downloaded it. I'm mostly interested in seeing how you manage > to translate data from postgresql to the client program. I mean: how > you recognize it's gis data and not just any blob... Because they are real types in PostgreSQL (one of the few backends out there that allows for user-defined types) and not just blobs of data. federico -- Federico Di Gregorio http://people.initd.org/fog Debian GNU/Linux Developer fog at debian.org INIT.D Developer fog at initd.org Those who do not study Lisp are doomed to reimplement it. Poorly. -- from Karl M. Hegbloom .signature -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio firmata digitalmente Url : http://mail.python.org/pipermail/db-sig/attachments/20061003/6aaaefb1/attachment.pgp From farcepest at gmail.com Tue Oct 3 16:01:00 2006 From: farcepest at gmail.com (Andy Dustman) Date: Tue, 3 Oct 2006 10:01:00 -0400 Subject: [DB-SIG] thoughts about OpenGIS extensions In-Reply-To: <1159879175.3796.42.camel@localhost> References: <20061003094911.GA19705@kruiskruid.demon.nl> <1159869310.3796.33.camel@localhost> <20061003111721.GB19864@kruiskruid.demon.nl> <1159879175.3796.42.camel@localhost> Message-ID: <9826f3800610030701p2781147fp83c39e5f5c9cad28@mail.gmail.com> On 10/3/06, Federico Di Gregorio wrote: > > I just downloaded it. I'm mostly interested in seeing how you manage > > to translate data from postgresql to the client program. I mean: how > > you recognize it's gis data and not just any blob... > > Because they are real types in PostgreSQL (one of the few backends out > there that allows for user-defined types) and not just blobs of data. FYI, they are also defined types in MySQL as well: http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html By default these would be returned as strings by MySQLdb, but you can add support for them with a couple lines of Python code if you have a function that does the necessary conversion into a Python type. (If you know a good standard Python library that does this, I'll add support. I looked into this once and didn't find a clear answer.) -- This message has been scanned for memes and dangerous content by MindScanner, and is believed to be unclean. From mfrasca at zonnet.nl Tue Oct 3 16:18:52 2006 From: mfrasca at zonnet.nl (Mario Frasca) Date: Tue, 3 Oct 2006 16:18:52 +0200 Subject: [DB-SIG] thoughts about OpenGIS extensions In-Reply-To: <9826f3800610030701p2781147fp83c39e5f5c9cad28@mail.gmail.com> References: <20061003094911.GA19705@kruiskruid.demon.nl> <1159869310.3796.33.camel@localhost> <20061003111721.GB19864@kruiskruid.demon.nl> <1159879175.3796.42.camel@localhost> <9826f3800610030701p2781147fp83c39e5f5c9cad28@mail.gmail.com> Message-ID: <20061003141852.GB25890@kruiskruid.demon.nl> On 2006-1003 10:01:00, Andy Dustman wrote: > if you have a > function that does the necessary conversion into a Python type. ... do we need here to know the internal data format used by mysql? on their web site I could not find it. the only reference I say is at http://dev.mysql.com/doc/refman/5.1/en/fetching-spatial-data.html, stating that ?Fetching geometry values using internal format can be useful in table-to-table transfers?. > (If > you know a good standard Python library that does this, I'll add > support. I looked into this once and didn't find a clear answer.) did you check Federico's link http://initd.org/tracker/psycopg/wiki/GeoTypes the page contains links to the downloadable tarballs. it looks quite nice, I'd say. Mario -- What difference does it make to the dead, the orphans and the homeless, whether the mad destruction is wrought under the name of totalitarianism or the holy name of liberty or democracy? Mahatma Gandhi (1869 - 1948), "Non-Violence in Peace and War" From farcepest at gmail.com Tue Oct 3 16:24:42 2006 From: farcepest at gmail.com (Andy Dustman) Date: Tue, 3 Oct 2006 10:24:42 -0400 Subject: [DB-SIG] thoughts about OpenGIS extensions In-Reply-To: <20061003141852.GB25890@kruiskruid.demon.nl> References: <20061003094911.GA19705@kruiskruid.demon.nl> <1159869310.3796.33.camel@localhost> <20061003111721.GB19864@kruiskruid.demon.nl> <1159879175.3796.42.camel@localhost> <9826f3800610030701p2781147fp83c39e5f5c9cad28@mail.gmail.com> <20061003141852.GB25890@kruiskruid.demon.nl> Message-ID: <9826f3800610030724o76431ce3s2d6cea45a380df9a@mail.gmail.com> On 10/3/06, Mario Frasca wrote: > On 2006-1003 10:01:00, Andy Dustman wrote: > > if you have a > > function that does the necessary conversion into a Python type. > > ... do we need here to know the internal data format used by mysql? > on their web site I could not find it. the only reference I say is > at http://dev.mysql.com/doc/refman/5.1/en/fetching-spatial-data.html, > stating that ?Fetching geometry values using internal format can be > useful in table-to-table transfers?. http://dev.mysql.com/doc/refman/5.0/en/supported-spatial-data-formats.html I think these are OpenGIS formats. > > > (If > > you know a good standard Python library that does this, I'll add > > support. I looked into this once and didn't find a clear answer.) > > did you check Federico's link > http://initd.org/tracker/psycopg/wiki/GeoTypes > the page contains links to the downloadable tarballs. > > it looks quite nice, I'd say. Indeed, might have to experiment with it. -- This message has been scanned for memes and dangerous content by MindScanner, and is believed to be unclean. From mfrasca at zonnet.nl Tue Oct 3 16:44:45 2006 From: mfrasca at zonnet.nl (Mario Frasca) Date: Tue, 3 Oct 2006 16:44:45 +0200 Subject: [DB-SIG] thoughts about OpenGIS extensions In-Reply-To: <9826f3800610030724o76431ce3s2d6cea45a380df9a@mail.gmail.com> References: <20061003094911.GA19705@kruiskruid.demon.nl> <1159869310.3796.33.camel@localhost> <20061003111721.GB19864@kruiskruid.demon.nl> <1159879175.3796.42.camel@localhost> <9826f3800610030701p2781147fp83c39e5f5c9cad28@mail.gmail.com> <20061003141852.GB25890@kruiskruid.demon.nl> <9826f3800610030724o76431ce3s2d6cea45a380df9a@mail.gmail.com> Message-ID: <20061003144445.GA26082@kruiskruid.demon.nl> Hallo Andy On 2006-1003 10:24:42, Andy Dustman wrote: > http://dev.mysql.com/doc/refman/5.0/en/supported-spatial-data-formats.html > > I think these are OpenGIS formats. yes and no: these are the formats returned by the translation functions asBinary and asText. both take a geometry object and return a representation in a 'well known' format, which are both different from the internal representation. a small python interaction to show the difference (from the mysql client you don't see anything) (I'm forcing geomFromText(...) to create a geometry object on the fly) >>> cr.execute("select geomFromText('POINT(34214.3412 34214.3412)')") 1L >>> cr.description (("geomFromText('POINT(34214.3412 34214.3412)')", 253, 25, 8192, 8192, 0, 0),) >>> cr.fetchone() ('\x00\x00\x00\x00\x01\x01\x00\x00\x00-C\x1c\xeb\xca\xb4\xe0 at -C\x1c\xeb\xca\xb4\xe0@',) >>> cr.execute("select asBinary(geomFromText('POINT(34214.3412 34214.3412)'))") 1L >>> cr.description (("asBinary(geomFromText('POINT(34214.3412 34214.3412)'))", 253, 21, 8192, 8192, 0, 0),) >>> cr.fetchone() ('\x01\x01\x00\x00\x00-C\x1c\xeb\xca\xb4\xe0 at -C\x1c\xeb\xca\xb4\xe0@',) >>> is the fact that the description field has the same '253' value for both internal and wkb formats going to be a problem? if I was _using_ mysqldb, I don't see a chance to distinguish the two things. but maybe _inside_ of mysqldb the distinction is made somehow. ah, well, you do see that the internal binary representation is different from the wkb one... as a user and even more as a library writer, I would not want to have to write a 'asBinary()' for each of my geometric fields. Mario -- everything done. Thank you for downloading a media file containing proprietary and patentend technology. From mfrasca at zonnet.nl Tue Oct 3 17:24:25 2006 From: mfrasca at zonnet.nl (Mario Frasca) Date: Tue, 3 Oct 2006 17:24:25 +0200 Subject: [DB-SIG] thoughts about OpenGIS extensions In-Reply-To: <20061003144445.GA26082@kruiskruid.demon.nl> References: <20061003094911.GA19705@kruiskruid.demon.nl> <1159869310.3796.33.camel@localhost> <20061003111721.GB19864@kruiskruid.demon.nl> <1159879175.3796.42.camel@localhost> <9826f3800610030701p2781147fp83c39e5f5c9cad28@mail.gmail.com> <20061003141852.GB25890@kruiskruid.demon.nl> <9826f3800610030724o76431ce3s2d6cea45a380df9a@mail.gmail.com> <20061003144445.GA26082@kruiskruid.demon.nl> Message-ID: <20061003152425.GA27339@kruiskruid.demon.nl> just a note about parsing points, which worked... >>> import GeoTypes ... >>> cr.execute("select asBinary(geomFromText('POINT(34214.3412 34214.3412)'))") 1L >>> obj = cr.fetchone()[0] >>> obj '\x01\x01\x00\x00\x00-C\x1c\xeb\xca\xb4\xe0 at -C\x1c\xeb\xca\xb4\xe0@' >>> cr.execute("select geomFromText('POINT(34214.3412 34214.3412)')") 1L >>> obj = cr.fetchone()[0] >>> obj '\x00\x00\x00\x00\x01\x01\x00\x00\x00-C\x1c\xeb\xca\xb4\xe0 at -C\x1c\xeb\xca\xb4\xe0@' >>> obj[4:] '\x01\x01\x00\x00\x00-C\x1c\xeb\xca\xb4\xe0 at -C\x1c\xeb\xca\xb4\xe0@' >>> g = GeoTypes.OGGeoTypeFactory() >>> p = GeoTypes.WKBParser(g) >>> p.parseGeometry(obj[4:]) >>> g.getGeometry() 34214.341200 34214.341200 >>> tried to parse polygons, but 17:30 is too late for clear thought... a domani (I'll be reading you tomorrow), Mario -- Die Welt wird nicht bedroht von den Menschen, die b?se sind, sondern von denen, die das B?se zulassen -- Albert Einstein From mfrasca at zonnet.nl Wed Oct 4 09:21:00 2006 From: mfrasca at zonnet.nl (Mario Frasca) Date: Wed, 4 Oct 2006 09:21:00 +0200 Subject: [DB-SIG] thoughts about OpenGIS extensions In-Reply-To: <1159879175.3796.42.camel@localhost> References: <20061003094911.GA19705@kruiskruid.demon.nl> <1159869310.3796.33.camel@localhost> <20061003111721.GB19864@kruiskruid.demon.nl> <1159879175.3796.42.camel@localhost> Message-ID: <20061004072100.GA14944@kruiskruid.demon.nl> On 2006-1003 14:39:35, Federico Di Gregorio wrote: > Il giorno mar, 03/10/2006 alle 13.17 +0200, Mario Frasca ha scritto: > > I can't remember if type adaptation and type-caster registration are > > a prerogative of psycopg2 or are in general available on all db-api2 > > modules. > > They are a prerogative of psycopg but other drivers offer similar > methods. is this the right place, I mean this db-sig, to propose that something like this be included in the next version of db-api? also: my initial posting was about trying to get something like... > > > This feature is used by the GeoTypes module that adds support > > > for all geometrical types to psycopg. See: > > > http://initd.org/tracker/psycopg/wiki/GeoTypes ... something like into Python, so that we could have a reference class hierarchy for OpenGIS objects, something that a db-api compliant module can rely on, rather than something that can use a db-api compliant module. the situation at the moment is that we have no reference class hierarchy for OpenGIS objects *and* that db-api compliant modules do not offer a standardized way to transform OpenGIS data from python to db and back. reading with interest the reactions from the group. MF -- Never, under any circumstances, take a sleeping pill and a laxative on the same night. From aprotin at research.att.com Tue Oct 17 20:04:45 2006 From: aprotin at research.att.com (Art Protin) Date: Tue, 17 Oct 2006 14:04:45 -0400 Subject: [DB-SIG] Clarification of API 2.0 wrt result sets Message-ID: <45351B3D.4040301@research.att.com> Dear folks, Since I could not find a FAQ for the API (other than in the API) let alone find my specific question, I guess I need to present it here. In its simplest form: When should a Cursor object discard a result set? After reading and rereading and ... the specification (dated 2006-03-28), I infer from the existence of the method .nextset() that a Cursor may (though not necessarily) queue up multiple result sets. I found only three (3) methods that produce result sets: .callproc(), .execute(), and .executemany(). Of these, the first two seem to be allowed to produce zero or one result sets and the behavior of the third is "undefined" if it produces even one result set. None of the descriptions for these three methods tell what to do with any result set from previous invocations. I am attempting to implement an interface that complies with the specification and can support multiple result sets (in a limited fashion by queuing up operations) if that is what a user would expect. Alternatively, I can make each new execution discard the previous result set. It is even possible to make the .executemany() do both the discard of previous results and queue up to generate result set after result set until either another invocation of one of the three or until .nextset() is invoked enough to go through all of them (presumably with intervening .fetchXXX() invocations. I think the spec should be revised to either: variant I: i) require a call to .nextset() to finish with each result set, and ii) until .nextset() returns False, make each of the three either: 1) queue up to execute after .nextset() finishes with the previous result sets, or 2) raise an exception for Cursor not ready. variant II: i) require each of the three to flush all previous result sets, and ii) not return from any of the three until all queries are completed variant III: i) have an attribute .queueable that reflects if any of the three will return before the query has been performed, where the attribute A) may be changed, or B) is readonly. (I think it best if the code allows write attempts on the attribute, but but may fail to change it so that the user should be required to check the value after attempting to set it. This would allow the specification to accommodate those that implement it switchable or with either fixed value.) (This goes into more detail than I intended but I do not see what to leave out.) Any comments will be appreciated. Thank you, Art Protin From mal at egenix.com Tue Oct 17 21:45:10 2006 From: mal at egenix.com (M.-A. Lemburg) Date: Tue, 17 Oct 2006 21:45:10 +0200 Subject: [DB-SIG] Clarification of API 2.0 wrt result sets In-Reply-To: <45351B3D.4040301@research.att.com> References: <45351B3D.4040301@research.att.com> Message-ID: <453532C6.2010706@egenix.com> Art Protin wrote: > Dear folks, > Since I could not find a FAQ for the API (other than in the API) let > alone find my specific question, I guess I need to present it here. In > its simplest form: > > When should a Cursor object discard a result set? > > After reading and rereading and ... the specification (dated > 2006-03-28), I infer from the existence of the method .nextset() that a > Cursor may (though not necessarily) queue up multiple result sets. I > found only three (3) methods that produce result sets: .callproc(), > .execute(), and .executemany(). Of these, the first two seem to be > allowed to produce zero or one result sets and the behavior of the third > is "undefined" if it produces even one result set. None of the > descriptions for these three methods tell what to do with any result set > from previous invocations. > I am attempting to implement an interface that complies with the > specification and can support multiple result sets (in a limited fashion > by queuing up operations) if that is what a user would expect. > Alternatively, I can make each new execution discard the previous result > set. This is what's intended: each new execute should free up the result from a previous execute (regardless of whether the method was .execute(), .executemany(), .callproc() or some other method creating result sets). If one of these creates multiple result sets, the first of these result sets should be made available to the user right after the call finished. The .nextset() method is intended to free the current result and move to the next result set (if any). > It is even possible to make the .executemany() do both the discard > of previous results and queue up to generate result set after result set > until either another invocation of one of the three or until .nextset() > is invoked enough to go through all of them (presumably with intervening > .fetchXXX() invocations. The behavior of .executemany() with respect to multiple result sets is undefined, because backends may implement result sets in ways that don't allow queuing. In practice, .executemany() should not be used to generate multiple result sets - it's main purpose is that of doing bulk inserts. You normally only create multiple result sets as output of a stored procedure. > I think the spec should be revised to either: > variant I: > i) require a call to .nextset() to finish with each result set, and > ii) until .nextset() returns False, make each of the three either: > 1) queue up to execute after .nextset() finishes with > the previous result sets, or > 2) raise an exception for Cursor not ready. > > variant II: > i) require each of the three to flush all previous result sets, and > ii) not return from any of the three until all queries are completed > > variant III: > i) have an attribute .queueable that reflects if any of the > three will return before the query has been performed, where the attribute > A) may be changed, or > B) is readonly. > (I think it best if the code allows write attempts on > the attribute, but but may fail to change it so that the user should be > required to check the value after attempting to set it. This would > allow the specification to accommodate those that implement it > switchable or with either fixed value.) > > (This goes into more detail than I intended but I do not see what to > leave out.) The above sounds too complicated. The general idea with multiple result sets is the same as for cursors - only that you're iterating over result sets instead of rows. Hope that clarifies things a bit, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 17 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 msmapper at gmail.com Wed Oct 25 06:14:31 2006 From: msmapper at gmail.com (Janice Sterling) Date: Tue, 24 Oct 2006 23:14:31 -0500 Subject: [DB-SIG] How to pass parameter with LIKE Message-ID: <402a50980610242114g7814725dn7cf1a94b3095cfa6@mail.gmail.com> I am trying to use a sql query where i'm passing a parameter sql_str = "SELECT mrc_code FROM blocks where mrc_code LIKE '%s'" % (blkfld) where blocks would be 31103a1, 31103e1, 31103a5, 31103e5 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/db-sig/attachments/20061024/fdf1fef5/attachment.htm From andy47 at halfcooked.com Wed Oct 25 11:44:12 2006 From: andy47 at halfcooked.com (Andy Todd) Date: Wed, 25 Oct 2006 19:44:12 +1000 Subject: [DB-SIG] How to pass parameter with LIKE In-Reply-To: <402a50980610242114g7814725dn7cf1a94b3095cfa6@mail.gmail.com> References: <402a50980610242114g7814725dn7cf1a94b3095cfa6@mail.gmail.com> Message-ID: <453F31EC.7040806@halfcooked.com> Janice Sterling wrote: > I am trying to use a sql query where i'm passing a parameter > > sql_str = "SELECT mrc_code FROM blocks where mrc_code LIKE '%s'" % (blkfld) > > where blocks would be 31103a1, 31103e1, 31103a5, 31103e5 > > > ------------------------------------------------------------------------ > That should be fine as long as you use bind parameters. Which database and DB-API module are you using? Regards, Andy -- -------------------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com/ From wilk-ml at flibuste.net Wed Oct 25 12:01:02 2006 From: wilk-ml at flibuste.net (William Dode) Date: Wed, 25 Oct 2006 10:01:02 +0000 (UTC) Subject: [DB-SIG] How to pass parameter with LIKE References: <402a50980610242114g7814725dn7cf1a94b3095cfa6@mail.gmail.com> Message-ID: On 25-10-2006, Janice Sterling wrote: > --===============0689749057== > Content-Type: multipart/alternative; > boundary="----=_Part_18939_12219789.1161749671700" > > ------=_Part_18939_12219789.1161749671700 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > I am trying to use a sql query where i'm passing a parameter > > sql_str = "SELECT mrc_code FROM blocks where mrc_code LIKE '%s'" % (blkfld) > > where blocks would be 31103a1, 31103e1, 31103a5, 31103e5 you want to do select mrc_code from blocks where mrc_code in ('31103a1', '31103e1', '31103a5', '31103e5') isnt'it ? -- William Dod? - http://flibuste.net From aprotin at research.att.com Wed Oct 25 17:40:42 2006 From: aprotin at research.att.com (Art Protin) Date: Wed, 25 Oct 2006 11:40:42 -0400 Subject: [DB-SIG] Additional DB API Extesions Message-ID: <453F857A.1000900@research.att.com> Dear folks, I am new to this group and I have not found an easy way to search the archives, so: 1) I need help finding the earlier discussion(s) about a method on class cursor for defining stored procedures; AND/OR 2) I want to discuss now such an extension so that what I implement is most similar to what other interfaces offer. Also has there been any discussion about extensions to support other query languages for those databases that have something besides SQL (as in a DBMS that supports SQL and its own non-SQL language)? Thank you all, Arthur Protin