From sumant.kuchipudi at gmail.com Wed Jan 6 15:24:42 2010 From: sumant.kuchipudi at gmail.com (Sumant Kuchipudi) Date: Wed, 6 Jan 2010 09:24:42 -0500 Subject: [DB-SIG] Help on ImportError:DLL load failed ... Message-ID: Hi, I was struggling with an error "ImportError: DLL load failed: The specified procedure could not be found." when I call import cx_Oracle module. I'm using Python 2.6 and for Oracle 11g, I've installed cx_Oracle 5.0.2 (also tried 5.0.1 and 5.0). I tried in google for help but no use, I found your question in mailing list forum, I think you definitely found the solution and expecting you the person will give my solution. Please reply me with the solution. Sumant -------------- next part -------------- An HTML attachment was scrubbed... URL: From maillist at schwertberger.de Thu Jan 7 12:56:03 2010 From: maillist at schwertberger.de (Dietmar Schwertberger) Date: Thu, 07 Jan 2010 12:56:03 +0100 Subject: [DB-SIG] Help on ImportError:DLL load failed ... In-Reply-To: References: Message-ID: <4B45CBD3.4030604@schwertberger.de> Sumant Kuchipudi schrieb: > I was struggling with an error "ImportError: DLL load failed: The > specified procedure could not be found." when I call import cx_Oracle > module. I'm using Python 2.6 and for Oracle 11g, I've installed > cx_Oracle 5.0.2 (also tried 5.0.1 and 5.0). I tried in google for help > but no use, I found your question in mailing list forum, I think you > definitely found the solution and expecting you the person will give my > solution. cx_Oracle requires that you have the Oracle client installed on your PC. Are you sure that you have this and that it's the right version? If you are using cx_Oracle for 11g, the client library should be the same version. The main DLL of the client is called oci.dll. You can view the version information of the DLL in the explorer. Regards, Dietmar From jimmy.briggs at gmail.com Thu Jan 7 13:36:58 2010 From: jimmy.briggs at gmail.com (James Briggs) Date: Thu, 7 Jan 2010 23:36:58 +1100 Subject: [DB-SIG] Help on ImportError:DLL load failed ... In-Reply-To: <23b1b67f1001070435p77acf60ch32ba0f4c9fe626b1@mail.gmail.com> References: <4B45CBD3.4030604@schwertberger.de> <23b1b67f1001070435p77acf60ch32ba0f4c9fe626b1@mail.gmail.com> Message-ID: <23b1b67f1001070436v50567231t210f9ad00a693af@mail.gmail.com> > > Client software available: > http://www.oracle.com/technology/software/tech/oci/instantclient/index.html > > The oci.dll file should be found on your path somewhere for the import > cx_Oracle to work. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dieter at handshake.de Thu Jan 7 14:20:26 2010 From: dieter at handshake.de (Dieter Maurer) Date: Thu, 7 Jan 2010 14:20:26 +0100 Subject: [DB-SIG] Help on ImportError:DLL load failed ... In-Reply-To: References: Message-ID: <19269.57242.167387.676768@gargle.gargle.HOWL> Sumant Kuchipudi wrote at 2010-1-6 09:24 -0500: >I was struggling with an error "ImportError: DLL load failed: The specified >procedure could not be found." when I call import cx_Oracle module. I'm >using Python 2.6 and for Oracle 11g, I've installed cx_Oracle 5.0.2 (also >tried 5.0.1 and 5.0). I tried in google for help but no use, I found your >question in mailing list forum, I think you definitely found the solution >and expecting you the person will give my solution. Usually, errors like this are caused by version problems. Somehow, the DLL does not fit the rest. To analyse such errors, you must determine which DLL could not be loaded and which symbol makes problems. The first information can usually be determined from the Python traceback. It tells you in which calling and code context an exception occured. The last line is especially relevant, it tells the place where the exception occured. Preceeding lines tell how you came there. The message looks like generated from an MS operating system. MS operating systems have the unfortunate tendancy not to name things in their problem describing messages: as above "some procedure" rather than "procedure XXX". I do not know how to find out under MS which symbol has problems. Maybe, you find something in the MS documentation (which is said to be good). Maybe, we already learn enough from the traceback.... -- Dieter From phd at phd.pp.ru Fri Jan 8 13:43:48 2010 From: phd at phd.pp.ru (Oleg Broytman) Date: Fri, 8 Jan 2010 15:43:48 +0300 Subject: [DB-SIG] SQLObject 0.11.3 Message-ID: <20100108124348.GC10206@phd.pp.ru> Hello! I'm pleased to announce version 0.11.3, a minor bugfix release of 0.11 branch of SQLObject. What is SQLObject ================= SQLObject is an object-relational mapper. Your database tables are described as classes, and rows are instances of those classes. SQLObject is meant to be easy to use and quick to get started with. SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB). Where is SQLObject ================== Site: http://sqlobject.org Development: http://sqlobject.org/devel/ Mailing list: https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss Archives: http://news.gmane.org/gmane.comp.python.sqlobject Download: http://cheeseshop.python.org/pypi/SQLObject/0.11.3 News and changes: http://sqlobject.org/News.html What's New ========== News since 0.11.2 ----------------- * The cache culling algorithm was enhanced to eliminate memory leaks by removing references to dead objects; tested on a website that runs around 4 million requests a day. * Fixed a bug in col.py and dbconnection.py - if dbEncoding is None suppose it's 'ascii'. * Fixed a bug in FirebirdConnection. For a more complete list, please see the news: http://sqlobject.org/News.html Oleg. -- Oleg Broytman http://phd.pp.ru/ phd at phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From phd at phd.pp.ru Fri Jan 8 13:45:43 2010 From: phd at phd.pp.ru (Oleg Broytman) Date: Fri, 8 Jan 2010 15:45:43 +0300 Subject: [DB-SIG] SQLObject 0.12.1 Message-ID: <20100108124543.GG10206@phd.pp.ru> Hello! I'm pleased to announce version 0.12.1, a bugfix release of branch 0.12 of SQLObject. What is SQLObject ================= SQLObject is an object-relational mapper. Your database tables are described as classes, and rows are instances of those classes. SQLObject is meant to be easy to use and quick to get started with. SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB). Where is SQLObject ================== Site: http://sqlobject.org Development: http://sqlobject.org/devel/ Mailing list: https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss Archives: http://news.gmane.org/gmane.comp.python.sqlobject Download: http://cheeseshop.python.org/pypi/SQLObject/0.12.1 News and changes: http://sqlobject.org/News.html What's New ========== News since 0.12.0 ----------------- * The cache culling algorithm was enhanced to eliminate memory leaks by removing references to dead objects; tested on a website that runs around 4 million requests a day. * Fixed a bug in col.py and dbconnection.py - if dbEncoding is None suppose it's 'ascii'. * Fixed three bugs in PostgresConnection. * Fixed a bug in FirebirdConnection. For a more complete list, please see the news: http://sqlobject.org/News.html Oleg. -- Oleg Broytman http://phd.pp.ru/ phd at phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From wiztricks at gmail.com Fri Jan 15 15:35:06 2010 From: wiztricks at gmail.com (wiztricks) Date: Fri, 15 Jan 2010 06:35:06 -0800 (PST) Subject: [DB-SIG] Having legs into diffents PostgreSQL versions?!? Message-ID: <27177664.post@talk.nabble.com> Hi Gents, I have old client/servers applications using PostgresSQL 7.2 or 7.3 (I don't remember for sure) which are components of an existing production system. In order to renew some parts of it without disturbing things that works, I figured out to isolate and confine the new stuff. Initially, customer planned to "upgrade" its PostgresSQL to 8.4, but other projects delayed the operation. So I may end having the "borders" of my stuff with a leg into 7.2 and another leg into 8.4. Well I mean having piece of code reading and writing db records from 7.2 and 8.4 databases. How can I get this mix working from a DBAPI point of view? Are someone aware of restrictions using such 'old' db drivers from Python 2.6 or later? Don't just tell me there are better places in the world...:-) I just try to figure out if we could get something workable for a couple of month, i.e. am I really stuck to wait the upgrade. -W -- View this message in context: http://old.nabble.com/Having-legs-into-diffents-PostgreSQL-versions-%21--tp27177664p27177664.html Sent from the Python - db-sig mailing list archive at Nabble.com. From chef at ghum.de Sat Jan 16 09:59:13 2010 From: chef at ghum.de (Massa, Harald Armin) Date: Sat, 16 Jan 2010 09:59:13 +0100 Subject: [DB-SIG] Having legs into diffents PostgreSQL versions?!? In-Reply-To: <27177664.post@talk.nabble.com> References: <27177664.post@talk.nabble.com> Message-ID: hey, > Well I mean having piece of code reading and writing db records from 7.2 and > 8.4 databases. > > How can I get this mix working from a DBAPI point of view? > Are someone aware of restrictions using such 'old' db drivers from Python > 2.6 or later? per definition the actual PostgreSQL driver shall be able to access also ancient versions of PostgreSQL; and you should also be able to profit from at least some of the bugfixes within the PostgreSQL connection libraries of the last oneandahalf decade. So: I recommend to you to go with the younges psycopg2 PostgreSQL driver. I also offer persuasion services to help people motivate themselfs, i.e. to upgrade PostgreSQL. Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Stra?e 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - %s is too gigantic of an industry to bend to the whims of reality From jd at commandprompt.com Sat Jan 16 18:30:58 2010 From: jd at commandprompt.com (Joshua D. Drake) Date: Sat, 16 Jan 2010 09:30:58 -0800 Subject: [DB-SIG] Having legs into diffents PostgreSQL versions?!? In-Reply-To: References: <27177664.post@talk.nabble.com> Message-ID: <1263663058.20966.2712.camel@jd-desktop.unknown.charter.com> On Sat, 2010-01-16 at 09:59 +0100, Massa, Harald Armin wrote: > hey, > > > Well I mean having piece of code reading and writing db records from 7.2 and > > 8.4 databases. > > > > How can I get this mix working from a DBAPI point of view? > > Are someone aware of restrictions using such 'old' db drivers from Python > > 2.6 or later? > > per definition the actual PostgreSQL driver shall be able to access > also ancient versions of PostgreSQL; and you should also be able to > profit from at least some of the bugfixes within the PostgreSQL > connection libraries of the last oneandahalf decade. > > So: I recommend to you to go with the younges psycopg2 PostgreSQL driver. > > I also offer persuasion services to help people motivate themselfs, > i.e. to upgrade PostgreSQL. That is correct, if you are running an old version, PostgreSQL will just default to the old protocol. However, I must say... the fact that you are running 7.2 is terrifying on a level that makes me have cold sweats and cry for mommy. You should be running *at least* 8.3. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir. From wiztricks at gmail.com Sat Jan 16 16:50:26 2010 From: wiztricks at gmail.com (wiztricks) Date: Sat, 16 Jan 2010 07:50:26 -0800 (PST) Subject: [DB-SIG] Having legs into diffents PostgreSQL versions?!? In-Reply-To: References: <27177664.post@talk.nabble.com> Message-ID: <27190807.post@talk.nabble.com> Hi Harald, Massa, Harald Armin wrote: > > per definition the actual PostgreSQL driver shall be able to access > also ancient versions of PostgreSQL; and you should also be able to > profit from at least some of the bugfixes within the PostgreSQL > connection libraries of the last oneandahalf decade. > I was so disappointed by customer delays to upgrade that I haven't looked at this possibility. But you're right the psycopg2 FAQ states that 7.* should works. Thanks to point this: you make my day! Could you elaborate a bit about "per definition the actual PostgreSQL..."? I mean is there a special sauce or did they follow some guidelines, rules... or PostgreSQL properties that warranty such ability of the psycopg2 drivers to work with different versions? Massa, Harald Armin wrote: > > I also offer persuasion services to help people motivate themselfs, i.e. > to upgrade PostgreSQL. > There is no question about the need to upgrade. But they have 50 client/server apps to check... and resource issues to do the work before I could land there. But with your tip, I don't think I should really care: we could totally disconnect new stuff delivery from database upgrade. -W -- View this message in context: http://old.nabble.com/Having-legs-into-diffents-PostgreSQL-versions-%21--tp27177664p27190807.html Sent from the Python - db-sig mailing list archive at Nabble.com. From fog at initd.org Sun Jan 17 11:07:44 2010 From: fog at initd.org (Federico Di Gregorio) Date: Sun, 17 Jan 2010 11:07:44 +0100 Subject: [DB-SIG] Having legs into diffents PostgreSQL versions?!? In-Reply-To: <27190807.post@talk.nabble.com> References: <27177664.post@talk.nabble.com> <27190807.post@talk.nabble.com> Message-ID: <4B52E170.8070803@initd.org> On 16/01/2010 16:50, wiztricks wrote: >> per definition the actual PostgreSQL driver shall be able to access >> > also ancient versions of PostgreSQL; and you should also be able to >> > profit from at least some of the bugfixes within the PostgreSQL >> > connection libraries of the last oneandahalf decade. >> > > I was so disappointed by customer delays to upgrade that I haven't looked at > this possibility. > But you're right the psycopg2 FAQ states that 7.* should works. > Thanks to point this: you make my day! Last psycopg2 versions depend on libpq features found in >= 8.3. It should be ok to compile against a modern libpq and then connect to an ancient backend but I never tried that. If it does not work just use an old version of psycopg1 togheter with psycopg2: they use different namespaces so you should be able to load and use them both at the same time. federico -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From chef at ghum.de Sun Jan 17 11:45:53 2010 From: chef at ghum.de (Massa, Harald Armin) Date: Sun, 17 Jan 2010 11:45:53 +0100 Subject: [DB-SIG] Having legs into diffents PostgreSQL versions?!? In-Reply-To: <27190807.post@talk.nabble.com> References: <27177664.post@talk.nabble.com> <27190807.post@talk.nabble.com> Message-ID: W., > Could you elaborate a bit about "per definition the actual PostgreSQL..."? > I mean is there a special sauce or did they follow some guidelines, rules... > or PostgreSQL properties that warranty such ability of the psycopg2 drivers > to work with different versions? it is nothing special to psycopg2, it is a feature of the PostgreSQL client libs (libpq), which are "wrapped" by psycopg2. And those PostgreSQL client libraries need that ability to provide an update/upgrade path: the standard PostgreSQL update routine is install new version, use new dump on old server, restore with new restore to new server. That way PostgreSQL has the chance to fix bugs in pg_dump. And to channel the words Joshua wrote: if a PostgreSQL core developer uses words like "cold sweats" and "cry for mommy", be sure to document (that is: using paper) that you really recommended that update and it was the sole decision of others to not do it now. Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Stra?e 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - %s is too gigantic of an industry to bend to the whims of reality From wiztricks at gmail.com Sun Jan 17 19:26:57 2010 From: wiztricks at gmail.com (wiztricks) Date: Sun, 17 Jan 2010 10:26:57 -0800 (PST) Subject: [DB-SIG] Having legs into diffents PostgreSQL versions?!? In-Reply-To: <4B52E170.8070803@initd.org> References: <27177664.post@talk.nabble.com> <27190807.post@talk.nabble.com> <4B52E170.8070803@initd.org> Message-ID: <27201429.post@talk.nabble.com> Hi Frederico, Federico Di Gregorio wrote: > > Last psycopg2 versions depend on libpq features found in >= 8.3. It > should be ok to compile against a modern libpq and then connect to an > ancient backend but I never tried that. If it does not work just use an > old version of psycopg1 togheter with psycopg2: they use different > namespaces so you should be able to load and use them both at the same > time. > Given your tips, psycopg2 over 7.2 does not look workable. Even if I am able to compile we could waste a lot of time to understand why the test suite does not work. Worse, if we get it working, any issue could open doubts and nightmares. Thus 7.2 data will be accessed through psycopg1 at the DBAPI level until database has been updated. We don't have so many dependencies on old datas for the first iteration: most reads, few tables,... When database will be updated, we will have to change the connexion string and pass few non reg. tests. We just have to get the database updated long before the second iteration - as it will have more dependencies with existing data. Anyway, thanks for your time and best regards - W -- View this message in context: http://old.nabble.com/Having-legs-into-diffents-PostgreSQL-versions-%21--tp27177664p27201429.html Sent from the Python - db-sig mailing list archive at Nabble.com. From bkline at rksystems.com Mon Jan 18 16:12:49 2010 From: bkline at rksystems.com (Bob Kline) Date: Mon, 18 Jan 2010 10:12:49 -0500 Subject: [DB-SIG] Why so many Python drivers for PostgreSQL? Message-ID: <4B547A71.1020503@rksystems.com> I've been search for information which would provide some background information on why there are so many choices for talking to PostgreSQL with Python, as well as guidance as to which of the options is the most widely used, most stable, most likely to be maintained in the future, has the fewest bugs, provides fullest feature support, etc. Are the deficiencies in each of the drivers so serious that so many programmers are driven to roll their own? Or are these the outgrowths of ambitious student projects? If anyone knows of such a guide (preferably not too horribly out of date), I'd be very grateful for a link. Lacking the existing of such a document, perhaps those of you who have been done serious work with the drivers would be willing to share what they have learned about the relative merits of what's out there. -- Bob Kline http://www.rksystems.com mailto:bkline at rksystems.com From jd at commandprompt.com Mon Jan 18 17:14:36 2010 From: jd at commandprompt.com (Joshua D. Drake) Date: Mon, 18 Jan 2010 08:14:36 -0800 Subject: [DB-SIG] Why so many Python drivers for PostgreSQL? In-Reply-To: <4B547A71.1020503@rksystems.com> References: <4B547A71.1020503@rksystems.com> Message-ID: <1263831276.9199.1.camel@jd-desktop.unknown.charter.com> On Mon, 2010-01-18 at 10:12 -0500, Bob Kline wrote: > I've been search for information which would provide some background > information on why there are so many choices for talking to PostgreSQL > with Python, as well as guidance as to which of the options is the most > widely used, most stable, most likely to be maintained in the future, > has the fewest bugs, provides fullest feature support, etc. Are the > deficiencies in each of the drivers so serious that so many programmers > are driven to roll their own? Or are these the outgrowths of ambitious > student projects? If anyone knows of such a guide (preferably not too > horribly out of date), I'd be very grateful for a link. Lacking the > existing of such a document, perhaps those of you who have been done > serious work with the drivers would be willing to share what they have > learned about the relative merits of what's out there. I can tell you that the only driver CMD uses is psycopg2. As far as I know all the drivers are DB-API compliant. Joshua D. Drake > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir. From bkline at rksystems.com Mon Jan 18 23:36:26 2010 From: bkline at rksystems.com (Bob Kline) Date: Mon, 18 Jan 2010 17:36:26 -0500 Subject: [DB-SIG] Why so many Python drivers for PostgreSQL? In-Reply-To: References: <4B547A71.1020503@rksystems.com> Message-ID: <4B54E26A.3060905@rksystems.com> Massa, Harald Armin wrote: > [... snip ...] > > So, my recommendations: > > if you are using Pyton 2.x, use psycopg2. > If you are using Python 3.x, please evaluate also py-postgresql > Excellent, thanks! Exactly the kind of information I was looking for. -- Bob Kline http://www.rksystems.com mailto:bkline at rksystems.com From cito at online.de Tue Jan 19 01:24:07 2010 From: cito at online.de (Christoph Zwerschke) Date: Tue, 19 Jan 2010 01:24:07 +0100 Subject: [DB-SIG] Why so many Python drivers for PostgreSQL? In-Reply-To: <4B547A71.1020503@rksystems.com> References: <4B547A71.1020503@rksystems.com> Message-ID: <4B54FBA7.6000600@online.de> Bob Kline wrote: > Are the deficiencies in each of the drivers so serious that so many > programmers are driven to roll their own? Or are these the > outgrowths of ambitious student projects? This has historical reasons. Python and PostgreSQL are both around for a long time and have evolved quite a bit, and there were two DBAPI releases. These developments prompted people to create new drivers using the new standards, but some of the older projects were not given up and modernized as well. PyGreSQL started even before DBAPI, but is still maintained and quite stable; it provides the old interface in addition to a newer DBAPI 2 module. pyPgSQL has the special feature of returning rows as dictionary. Psycopg2 is more modern, sophisticated (built-in connection pooling) and can be considered the mainstream. Then of course, there are also drivers for platforms different from traditional CPython, such as JDBC, .NET, pure Python drivers etc. -- Christoph From fog at initd.org Tue Jan 19 08:23:01 2010 From: fog at initd.org (Federico Di Gregorio) Date: Tue, 19 Jan 2010 08:23:01 +0100 Subject: [DB-SIG] Why so many Python drivers for PostgreSQL? In-Reply-To: <4B54FBA7.6000600@online.de> References: <4B547A71.1020503@rksystems.com> <4B54FBA7.6000600@online.de> Message-ID: <4B555DD5.3070708@initd.org> On 19/01/2010 01:24, Christoph Zwerschke wrote: > Bob Kline wrote: >> Are the deficiencies in each of the drivers so serious that so many >> programmers are driven to roll their own? Or are these the >> outgrowths of ambitious student projects? > > This has historical reasons. Python and PostgreSQL are both around for a > long time and have evolved quite a bit, and there were two DBAPI > releases. These developments prompted people to create new drivers using > the new standards, but some of the older projects were not given up and > modernized as well. PyGreSQL started even before DBAPI, but is still > maintained and quite stable; it provides the old interface in addition > to a newer DBAPI 2 module. pyPgSQL has the special feature of returning > rows as dictionary. Psycopg2 is more modern, sophisticated (built-in > connection pooling) and can be considered the mainstream. Then of > course, there are also drivers for platforms different from traditional > CPython, such as JDBC, .NET, pure Python drivers etc. In fact the main feature of psycopg is not connection pooling (just an extra to show the possibility to subclass connection and cursor objects) but type adaptation that let you specify how to convert any Python type to PostgreSQL and back. If you want a row as a dictionary you just need to subclass cursor and pass the new type to the connection and voil?!, your new cursor can override the fetchXXX methods and build dicts instead of tuples (in fact this example is included in the psycopg2.extras module.) federico -- Federico Di Gregorio 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: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From bkline at rksystems.com Tue Jan 19 12:55:43 2010 From: bkline at rksystems.com (Bob Kline) Date: Tue, 19 Jan 2010 06:55:43 -0500 Subject: [DB-SIG] Why so many Python drivers for PostgreSQL? In-Reply-To: <4B555DD5.3070708@initd.org> References: <4B547A71.1020503@rksystems.com> <4B54FBA7.6000600@online.de> <4B555DD5.3070708@initd.org> Message-ID: <4B559DBF.1030602@rksystems.com> Federico Di Gregorio wrote: >> ... Psycopg2 is more modern, sophisticated (built-in >> connection pooling) and can be considered the mainstream. >> > .... > > If you want a row as a dictionary you just need to subclass cursor ... Thanks to both of you for the additional background and insight. All of the responses appear to lean toward psycopg2 as the driver most likely to be around for the long haul. -- Bob Kline http://www.rksystems.com mailto:bkline at rksystems.com From Chris.Clark at ingres.com Fri Jan 22 00:07:16 2010 From: Chris.Clark at ingres.com (Chris Clark) Date: Thu, 21 Jan 2010 15:07:16 -0800 Subject: [DB-SIG] Any IronPython users? Message-ID: <4B58DE24.4080305@ingres.com> Thought I'd check here before I post to the IronPython list. Is anyone here using IronPython with (any kind of) dbapi driver? I pulled down FePy http://fepy.sourceforge.net/ a few months back, added support for Ingres and fixed some problems related to date types (type support was incomplete). I emailed the changes back to the author but I've not had a response. Is FePy what other people are using? Are the other options? Any advice/hints would be appreciated as I'm not a huge IronPython user but I'm finding it handy every now and then and I'd like to make sure I'm using a maintained driver. I'm not looking to take on responsibilty for an IronPython driver to data adapters but I'm happy to contribute patches when I find problems :-) Chris