From 33IAuj2ea@worktow1est.com Fri Jan 2 12:00:08 1998 From: 33IAuj2ea@worktow1est.com (33IAuj2ea@worktow1est.com) Date: 02 Jan 98 12:00:08 AM Subject: [DB-SIG] Give Your Child "One of the Best Children's Videos"" Message-ID: <8R7Tua9Wv6> The holidays are upon us. If you're like a lot of people, you struggle to find gifts for your children that will entertain and amuse them at the same time. Well, here's a gift that will delight your child - A Is For Airplane! "A Is For Airplane" is the award-winning educational video that shows kids all the fun and teamwork involved in running an airline. "A Is For Airplane" gets viewers behind the scenes at the airport! Kids get to see: * The ticket counter! * Inside the baggage system! * On the ramp with the baggage loaders and fuelers! * In the catering kitchens! * Inside the control tower! * In the hangar with the mechanics! * At the boarding gate! * And even in the COCKPIT of a real Boeing 757! Parenting Magazine calls "A Is For Airplane" "One of the Best Videos of 1996!" It's also Approved by the Parent's Choice Foundation! Thousands of copies of "A Is For Airplane" have been sold for $14.95, but as an Internet Special this holiday season you can get "A Is For Airplane" for only $11.95 (plus shipping and handling.) ORDER TODAY FOR GUARANTEED HOLIDAY DELIVERY! You can order "A Is For Airplane" by calling our toll-free number - 800-250-4210. If you'd like more information, visit our Website at www.ppmm.com/jfp/jfp1297.htm or CLICK HERE! Thank you for your time... Johnson Family Productions Madison, WI _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Thu Jan 8 19:47:54 1998 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Thu, 08 Jan 1998 20:47:54 +0100 Subject: [DB-SIG] ANN: Date/Time C extension, version 0.4 Message-ID: <34B52D6A.265908CF@uni-duesseldorf.de> The new release makes the set of types/functions and constructors more or less complete. It can now handle arbitrary dates and times, does simple date/time calculations and allows dates and times to be used as dictionary keys (i.e. hashing and comparing is also supported). Getting all the types coerced properly was a real nasty fight with Python's coercion mechanism: we should really fix this to allow for "mixed" type coercion ! Please have a look and tell me what you think: http://starship.skyport.net/~lemburg/mxDateTime.html If there is a consensus, I'll make these types the low-level standard for database interfacing in the upcoming DB API Spec 1.1. The DateTime module provides a C API in form of a C object for this reason. -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Fri Jan 9 11:12:59 1998 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Fri, 09 Jan 1998 12:12:59 +0100 Subject: [DB-SIG] Re: ANN: Date/Time C extension, version 0.4 References: <34B52D6A.265908CF@uni-duesseldorf.de> Message-ID: <34B6063B.5630B43B@uni-duesseldorf.de> M.-A. Lemburg wrote: > > The new release makes the set of types/functions and constructors > more or less complete. It can now handle arbitrary dates and times, does > simple date/time calculations and allows dates and times to be used > as dictionary keys (i.e. hashing and comparing is also supported). > > Getting all the types coerced properly was a real nasty fight > with Python's coercion mechanism: we should really fix this to allow > for "mixed" type coercion ! > > Please have a look and tell me what you think: > > http://starship.skyport.net/~lemburg/mxDateTime.html > > If there is a consensus, I'll make these types the low-level > standard for database interfacing in the upcoming DB API Spec 1.1. > The DateTime module provides a C API in form of a C object for > this reason. One thing I forgot to make clear: The module's interface may still change until version 1.0 is out. You shouldn't be using the module in production code yet. It is currently meant as test bed implementation, to get a feeling of how date/time handling in Python should work. Sorry for any inconvenience... -- cheers, Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From sdelalic@icos.si Fri Jan 9 11:21:10 1998 From: sdelalic@icos.si (Sedad Delalic) Date: Fri, 09 Jan 1998 12:21:10 +0100 Subject: [DB-SIG] Questions about DB-API? Message-ID: <34B60826.608D@icos.si> Hello, after few days spent in testing an existing db-api (informixdb) I would like to ask you few questions : 1. Is the mapping of NULL value defined? I did not see any comment about that. 2. What will happened with DATE type ? - Current definition of date type (time) in python cannot handle dates before the 01/01/1970. DBMSs (many of them) support that. Thank you in advance. _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Sun Jan 11 00:45:17 1998 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Sun, 11 Jan 1998 01:45:17 +0100 Subject: [DB-SIG] Questions about DB-API? References: <34B60826.608D@icos.si> Message-ID: <34B8161D.22ADD2A8@uni-duesseldorf.de> Sedad Delalic wrote: > > Hello, > after few days spent in testing an existing db-api (informixdb) I would > like to ask you few questions : > > 1. Is the mapping of NULL value defined? I did not see any comment about > that. No, but the 1.1 API version will define this as None. See http://starship.skyport.net/crew/lemburg/DatabaseAPI-1.1.html for details. > > 2. What will happened with DATE type ? > - Current definition of date type (time) in python cannot handle > dates before the 01/01/1970. DBMSs (many of them) support that. As soon as I have the date/time types stable, you can use those. They don't have any problem with dates from 1.1.1 to well beyond 1.1.100000. See http://starship.skyport.net/crew/lemburg/mxDateTime.html for details. -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From kenny@kc.net Wed Jan 14 21:42:45 1998 From: kenny@kc.net (kenny@kc.net) Date: Wed, 14 Jan 1998 15:42:45 -0600 Subject: [DB-SIG] http://www.python.org/sigs/db-sig/DatabaseAPI.html Message-ID: <199801142142.PAA04827@orator.the-b.org> I was wondering if there were any plans to support the Essentia database from www.inter-soft.com. It is free for Linux and has ODBC drivers for Windows. _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Wed Jan 14 23:50:02 1998 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Thu, 15 Jan 1998 00:50:02 +0100 Subject: [DB-SIG] http://www.python.org/sigs/db-sig/DatabaseAPI.html References: <199801142142.PAA04827@orator.the-b.org> Message-ID: <34BD4F2A.1026BF89@uni-duesseldorf.de> kenny@kc.net wrote: > > I was wondering if there were any plans to support the Essentia database > from www.inter-soft.com. It is free for Linux and has ODBC drivers for > Windows. Hmm, I think there's not much to port :-) The ODBC-driver for Linux should (in theory) work together with my mxODBC-interface: http://starship.skyport.net/~lemburg/mxODBC.html Note: a new version will appear in a couple of days or weeks. That version will then contain full support for the Date/Time types I wrote (the current version doesn't handle TIME columns correctly: they are returned as DateTime-instance. -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From white@fnal.gov Thu Jan 15 19:39:27 1998 From: white@fnal.gov (Vicky White) Date: Thu, 15 Jan 1998 13:39:27 -0600 Subject: [DB-SIG] Oracle interface for Windows/NT Message-ID: <34BE65EF.B4432704@fnal.gov> This is a multi-part message in MIME format. --------------10470A928E036742F7CD97B4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have been using the Digital creations database API module for oracle and have been following all the discussions on date/time. I am working with it on Sun/Solaris -but intend to also use it on SGI and Linux, which should not be a problem. I just assumed that it would be easy to get it (or something else) with the standard DB API working under NT/windows. However, now that I start looking closely I find nothing specifically for windows. Of the 3 things available the Digital Creations API the Lemburg mxODBC module and Oramod (which I can find nothing for - only patches?) nothing seems to be designed for a windows environment. Do I really have to take the c code and the Python documentation and figure it all out myself -(not being much of a windows person). Someone out there please give me help and guidance and if you have built a DBI interface to Oracle on windows please share your knowledge and experiences. Or am I looking in the wrong places? Vicky White --------------10470A928E036742F7CD97B4 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Victoria White Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Victoria White n: White;Victoria org: Dzero Experiment and Computing Division email;internet: white@fnal.gov title: Assoc. Head Computing Division x-mozilla-cpt: ;0 x-mozilla-html: TRUE version: 2.1 end: vcard --------------10470A928E036742F7CD97B4-- _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From caryc@shore.net Thu Jan 15 20:22:57 1998 From: caryc@shore.net (Cary Collett) Date: Thu, 15 Jan 1998 15:22:57 -0500 (EST) Subject: [DB-SIG] Oracle interface for Windows/NT In-Reply-To: <34BE65EF.B4432704@fnal.gov> from "Vicky White" at Jan 15, 98 01:39:27 pm Message-ID: <199801152022.PAA02464@shell2.shore.net> > > I have been using the Digital creations database API module for oracle > and have been following all the discussions on date/time. I am working > with it on Sun/Solaris -but intend to also use it on SGI and Linux, > which should not be a problem. I just assumed that it would be easy to > get it (or something else) with the standard DB API working under > NT/windows. However, now that I start looking closely I find nothing > specifically for windows. Of the 3 things available > the Digital Creations API > the Lemburg mxODBC module > and Oramod (which I can find nothing for - only patches?) > How do you plan to get it working under Linux? No native Oracle libraries. Though you could compile Python and oracledb under SCO and then use the IBCS to run it under Linux. Cary _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From pi4kL8wS6@a1oI.com Wed Jan 14 03:33:50 1998 From: pi4kL8wS6@a1oI.com (pi4kL8wS6@a1oI.com) Date: 14 Jan 98 3:33:50 PM Subject: [DB-SIG] Let Us Do It For You! Message-ID: <9wUt06cX9ymS3gA2v> LET US DO YOUR BULK MAILINGS!!! ..$350 PER MILLION ADDRESSES SENT ..$250 PER 1/2 MILLION ADDRESSES SENT THE WAY OF THE FUTURE FOR SUCCESS IN YOUR BUSINESS! Our company will do bulk emailing for your product/service. Addresses are extracted daily by six of our computers, which run 24 hours a day 7 days a week, scanning the net for new addresses. Estimated 60-80,000 addresses extracted daily. They are fresh! Over 40 million addresses on file. No more than 2 pages (50 lines), no porn and no foul language. $50 per page/25 lines per page beyond 2 pages. We do not do targeted mailings at this price. Targeted mailings: $150 per 50,000 addresses extracted or less. We can extract by country, occupation, organizations, associations, product, etc. If we can not search and extract what you need, then nobody can. There are no lower prices on the net. Your mailing can be done in a matter of hours. We have 6 computers extracting addresses 24/7. For the fastest service, cheapest prices and cleanest mailings call our processing and new accounts office at 904-282-0945, Monday - Friday 9 - 5 EST. If the line is busy, please keep trying, as bulk mailing is growing fast. We do want to work with you to advertise your product. To have your name removed, call our processing office. Any negative responses will be dealt with accordingly. _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From jim@digicool.com Thu Jan 15 20:56:44 1998 From: jim@digicool.com (Jim Fulton) Date: Thu, 15 Jan 1998 15:56:44 -0500 Subject: [DB-SIG] Oracle interface for Windows/NT References: <34BE65EF.B4432704@fnal.gov> Message-ID: <34BE780C.1AA9@digicool.com> Vicky White wrote: > > I have been using the Digital creations database API module for oracle > and have been following all the discussions on date/time. I am working > with it on Sun/Solaris -but intend to also use it on SGI and Linux, > which should not be a problem. I just assumed that it would be easy to > get it (or something else) with the standard DB API working under > NT/windows. However, now that I start looking closely I find nothing > specifically for windows. We use a number of extension modules in our products. None of them have windows-specific code (other than the delay of setting a new type's type to PyType_Type until the init function). Uh, I just noticed that this hasn't been done yet for the oracle module. :-( Here's what has to be done: 1. Change every line that looks like: PyObject_HEAD_INIT (&PyType_Type) and change it to look like: PyObject_HEAD_INIT (NULL) 2. And then, for each type defined in the module, add a line like the following in the module init function: Cursor_Type.ob_type=&PyType_Type; That's the only C change that *should* be necessary. This does no harm on Unix, so we write all new C modules this way. > Of the 3 things available > the Digital Creations API > the Lemburg mxODBC module > and Oramod (which I can find nothing for - only patches?) Have you tried the ODBC binary that comes with PythonWin? > nothing seems to be designed for a windows environment. None of our modules are "designed" for windows. We use the same sources on windows and Unix. Of course, you need a Windows-specific make file. Do you know how to make one of these? > Do I really > have to take the c code and the Python documentation and figure it all > out myself -(not being much of a windows person). Not all of it. > Someone out there > please give me help and guidance and if you have built a DBI interface > to Oracle on windows please share your knowledge and experiences. If someone has successfully built the oracle module on windows and is willing to share their binary, I'd be happy to include it on out website. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creattions http://www.digicool.com http://www.python.org _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From white@fnal.gov Sat Jan 17 20:16:48 1998 From: white@fnal.gov (Victoria White) Date: Sat, 17 Jan 1998 14:16:48 -0600 Subject: [DB-SIG] Oracle interface for Windows/NT References: <199801152022.PAA02464@shell2.shore.net> Message-ID: <34C111B0.749AE842@fnal.gov> This is a multi-part message in MIME format. --------------86A707696B7C085BED3B52A1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cary, Yes that was the initial plan - but if there are other suggestions I would be happy to hear them. Vicky Cary Collett wrote: > > > > I have been using the Digital creations database API module for oracle > > and have been following all the discussions on date/time. I am working > > with it on Sun/Solaris -but intend to also use it on SGI and Linux, > > which should not be a problem. I just assumed that it would be easy to > > get it (or something else) with the standard DB API working under > > NT/windows. However, now that I start looking closely I find nothing > > specifically for windows. Of the 3 things available > > the Digital Creations API > > the Lemburg mxODBC module > > and Oramod (which I can find nothing for - only patches?) > > > > How do you plan to get it working under Linux? No native Oracle > libraries. Though you could compile Python and oracledb under SCO and > then use the IBCS to run it under Linux. > > Cary --------------86A707696B7C085BED3B52A1 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Victoria White Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Victoria White n: White;Victoria org: Fermi National Accelerator Lab email;internet: white@fnal.gov title: Associate Head, Computing Division x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------86A707696B7C085BED3B52A1-- _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From white@fnal.gov Sat Jan 17 21:19:19 1998 From: white@fnal.gov (Victoria White) Date: Sat, 17 Jan 1998 15:19:19 -0600 Subject: [DB-SIG] Oracle interface for Windows/NT References: <34BE65EF.B4432704@fnal.gov> <34BE780C.1AA9@digicool.com> Message-ID: <34C12057.C5C32669@fnal.gov> This is a multi-part message in MIME format. --------------65D2BDC0546C8683C9391B3A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jim, Thank you for your reply. I have still not heard from anyone who has actually got your oracledb module working under Windows/NT. At your suggestion I tried the dbi and odbc modules in Pythonwin. The documentation of these is obscure, but eventually I came upon it. However, the description of the bugs and limitations and the lack of anyone using/supporting it was not a happy discovery. I am certainly able to connect to the oracle database and do some simple things. Have not yet figured out what to do about date/time and raw data types. If I could locate others using either oracledb or the mxODBC module I would feel more comfortable using one of them - but looks like I have to build one or other of oracledb or mxODBC myself - as an extension module. In reference to this you talk about an NT-specific make file? Are you assuming I will have to import the gnu tools and compiler to my NT system and not use the Microsoft Visual C++ environment, for example? As I said in my first mail I really have no clue what I am doing on NT and don't particularly want to go deeply into it. So once again - please someone - share your ready-built and ready-to-run Win32 oracledb or mxODBC module with me if you have already done this. Or at least your 10 step recipe. Also let me know who else is using the built-in dbi and odbc in PythonWin. Has anyone fixed any of the known bugs? Thanks a lot in advance Vicky Also - I think someone should remove the oramod stuff from the web pages and archive. The only files that seem to be there are patches. These date from 1995 and the web page associated with the product says the author has abandoned it. It is simply confusing to people to have out-of-date and usupported stuff offered in the Python archives. Jim Fulton wrote: > Vicky White wrote: > > > > I have been using the Digital creations database API module for oracle > > and have been following all the discussions on date/time. I am working > > with it on Sun/Solaris -but intend to also use it on SGI and Linux, > > which should not be a problem. I just assumed that it would be easy to > > get it (or something else) with the standard DB API working under > > NT/windows. However, now that I start looking closely I find nothing > > specifically for windows. > > We use a number of extension modules in our products. None of them > have windows-specific code (other than the delay of setting a new type's > type to PyType_Type until the init function). > > Uh, I just noticed that this hasn't been done yet for the > oracle module. :-( Here's what has to be done: > > 1. Change every line that looks like: > > PyObject_HEAD_INIT (&PyType_Type) > > and change it to look like: > > PyObject_HEAD_INIT (NULL) > > 2. And then, for each type defined in the module, add a line like the > following in the module init function: > > Cursor_Type.ob_type=&PyType_Type; > > That's the only C change that *should* be necessary. This does > no harm on Unix, so we write all new C modules this way. > > > Of the 3 things available > > the Digital Creations API > > the Lemburg mxODBC module > > and Oramod (which I can find nothing for - only patches?) > > Have you tried the ODBC binary that comes with PythonWin? > > > nothing seems to be designed for a windows environment. > > None of our modules are "designed" for windows. We use the same sources > on windows and Unix. > > Of course, you need a Windows-specific make file. Do you know > how to make one of these? > > > Do I really > > have to take the c code and the Python documentation and figure it all > > out myself -(not being much of a windows person). > > Not all of it. > > > Someone out there > > please give me help and guidance and if you have built a DBI interface > > to Oracle on windows please share your knowledge and experiences. > > If someone has successfully built the oracle module on > windows and is willing to share their binary, I'd be happy to > include it on out website. > > Jim > > -- > Jim Fulton mailto:jim@digicool.com > Technical Director (540) 371-6909 Python Powered! > Digital Creattions http://www.digicool.com http://www.python.org --------------65D2BDC0546C8683C9391B3A Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Victoria White Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Victoria White n: White;Victoria org: Fermi National Accelerator Lab email;internet: white@fnal.gov title: Associate Head, Computing Division x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------65D2BDC0546C8683C9391B3A-- _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From billtut@microsoft.com Sat Jan 17 22:29:47 1998 From: billtut@microsoft.com (Bill Tutt) Date: Sat, 17 Jan 1998 14:29:47 -0800 Subject: [DB-SIG] Oracle interface for Windows/NT Message-ID: <4D0A23B3F74DD111ACCD00805F31D8104537E2@red-msg-50.dns.microsoft.com> I'd be more than willing to answer ANY questions you might have about the PythonWin dbi, and odbc modules. Bill More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason ---including blind stupidity. > Python: the power of simplicity > Perl: the power of obscurity > > > > -----Original Message----- > From: Victoria White [SMTP:white@fnal.gov] > Sent: Saturday, January 17, 1998 1:19 PM > To: jim@digicool.com > Cc: DB-SIG@python.org > Subject: Re: [DB-SIG] Oracle interface for Windows/NT > > Jim, > Thank you for your reply. I have still not heard from anyone who > has > actually got your oracledb module working under Windows/NT. > At your suggestion I tried the dbi and odbc modules in Pythonwin. The > documentation of these is obscure, but eventually I came upon it. > However, > the description of the bugs and limitations and the lack of anyone > using/supporting it was not a happy discovery. I am certainly able to > connect to the oracle database and do some simple things. Have not yet > figured out what to do about date/time and raw data types. If I could > locate others using either oracledb or the mxODBC module I would feel more > comfortable using one of them - but looks like I have to build one or > other > of oracledb or mxODBC myself - as an extension module. > > In reference to this you talk about an NT-specific make file? Are you > assuming I will have to import the gnu tools and compiler to my NT system > and > not use the Microsoft Visual C++ environment, for example? As I said in > my > first mail I really have no clue what I am doing on NT and don't > particularly > want to go deeply into it. So once again - please someone - share your > ready-built and ready-to-run Win32 oracledb or mxODBC module with me if > you > have already done this. Or at least your 10 step recipe. Also let me > know > who else is using the built-in dbi and odbc in PythonWin. Has anyone > fixed > any of the known bugs? > > Thanks a lot in advance > Vicky > > Also - I think someone should remove the oramod stuff from the web pages > and > archive. The only files that seem to be there are patches. These date > from > 1995 and the web page associated with the product says the author has > abandoned it. It is simply confusing to people to have out-of-date and > usupported stuff offered in the Python archives. > > Jim Fulton wrote: > > > Vicky White wrote: > > > > > > I have been using the Digital creations database API module for oracle > > > and have been following all the discussions on date/time. I am working > > > with it on Sun/Solaris -but intend to also use it on SGI and Linux, > > > which should not be a problem. I just assumed that it would be easy > to > > > get it (or something else) with the standard DB API working under > > > NT/windows. However, now that I start looking closely I find nothing > > > specifically for windows. > > > > We use a number of extension modules in our products. None of them > > have windows-specific code (other than the delay of setting a new type's > > type to PyType_Type until the init function). > > > > Uh, I just noticed that this hasn't been done yet for the > > oracle module. :-( Here's what has to be done: > > > > 1. Change every line that looks like: > > > > PyObject_HEAD_INIT (&PyType_Type) > > > > and change it to look like: > > > > PyObject_HEAD_INIT (NULL) > > > > 2. And then, for each type defined in the module, add a line like the > > following in the module init function: > > > > Cursor_Type.ob_type=&PyType_Type; > > > > That's the only C change that *should* be necessary. This does > > no harm on Unix, so we write all new C modules this way. > > > > > Of the 3 things available > > > the Digital Creations API > > > the Lemburg mxODBC module > > > and Oramod (which I can find nothing for - only patches?) > > > > Have you tried the ODBC binary that comes with PythonWin? > > > > > nothing seems to be designed for a windows environment. > > > > None of our modules are "designed" for windows. We use the same sources > > on windows and Unix. > > > > Of course, you need a Windows-specific make file. Do you know > > how to make one of these? > > > > > Do I really > > > have to take the c code and the Python documentation and figure it all > > > out myself -(not being much of a windows person). > > > > Not all of it. > > > > > Someone out there > > > please give me help and guidance and if you have built a DBI interface > > > to Oracle on windows please share your knowledge and experiences. > > > > If someone has successfully built the oracle module on > > windows and is willing to share their binary, I'd be happy to > > include it on out website. > > > > Jim > > > > -- > > Jim Fulton mailto:jim@digicool.com > > Technical Director (540) 371-6909 Python Powered! > > Digital Creattions http://www.digicool.com http://www.python.org > > << File: Card for Victoria White >> _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From gstein@exchange.microsoft.com Mon Jan 19 09:07:41 1998 From: gstein@exchange.microsoft.com (Greg Stein (Exchange)) Date: Mon, 19 Jan 1998 01:07:41 -0800 Subject: [DB-SIG] Oracle interface for Windows/NT Message-ID: <69D8143E230DD111B1D40000F848584001E53F44@ED> The ODBC module has been used extensively against Oracle databases, including the use of dates and raw values. It was quite capable and had everything needed. It is certainly more straightforward than trying to use oracledb on NT, which I seriously doubt anybody has done, which means that you'd be working with something even less stable than the ODBC module. I believe mxODBC was intended for Unix platforms. Since it uses the same interface as the win32 ODBC module, I don't see that it would actually provide any additional benefit, and it, too, has certainly been used less than the win32 ODBC module. In any case, just try it. If you run into problems, then come back here. As Bill said, he'll gladly help out with questions. Others here will, too, I'm sure. -g -----Original Message----- From: Victoria White [SMTP:white@fnal.gov] Sent: Saturday, January 17, 1998 1:19 PM To: jim@digicool.com Cc: DB-SIG@python.org Subject: Re: [DB-SIG] Oracle interface for Windows/NT Jim, Thank you for your reply. I have still not heard from anyone who has actually got your oracledb module working under Windows/NT. At your suggestion I tried the dbi and odbc modules in Pythonwin. The documentation of these is obscure, but eventually I came upon it. However, the description of the bugs and limitations and the lack of anyone using/supporting it was not a happy discovery. I am certainly able to connect to the oracle database and do some simple things. Have not yet figured out what to do about date/time and raw data types. If I could locate others using either oracledb or the mxODBC module I would feel more comfortable using one of them - but looks like I have to build one or other of oracledb or mxODBC myself - as an extension module. In reference to this you talk about an NT-specific make file? Are you assuming I will have to import the gnu tools and compiler to my NT system and not use the Microsoft Visual C++ environment, for example? As I said in my first mail I really have no clue what I am doing on NT and don't particularly want to go deeply into it. So once again - please someone - share your ready-built and ready-to-run Win32 oracledb or mxODBC module with me if you have already done this. Or at least your 10 step recipe. Also let me know who else is using the built-in dbi and odbc in PythonWin. Has anyone fixed any of the known bugs? Thanks a lot in advance Vicky Also - I think someone should remove the oramod stuff from the web pages and archive. The only files that seem to be there are patches. These date from 1995 and the web page associated with the product says the author has abandoned it. It is simply confusing to people to have out-of-date and usupported stuff offered in the Python archives. Jim Fulton wrote: > Vicky White wrote: > > > > I have been using the Digital creations database API module for oracle > > and have been following all the discussions on date/time. I am working > > with it on Sun/Solaris -but intend to also use it on SGI and Linux, > > which should not be a problem. I just assumed that it would be easy to > > get it (or something else) with the standard DB API working under > > NT/windows. However, now that I start looking closely I find nothing > > specifically for windows. > > We use a number of extension modules in our products. None of them > have windows-specific code (other than the delay of setting a new type's > type to PyType_Type until the init function). > > Uh, I just noticed that this hasn't been done yet for the > oracle module. :-( Here's what has to be done: > > 1. Change every line that looks like: > > PyObject_HEAD_INIT (&PyType_Type) > > and change it to look like: > > PyObject_HEAD_INIT (NULL) > > 2. And then, for each type defined in the module, add a line like the > following in the module init function: > > Cursor_Type.ob_type=&PyType_Type; > > That's the only C change that *should* be necessary. This does > no harm on Unix, so we write all new C modules this way. > > > Of the 3 things available > > the Digital Creations API > > the Lemburg mxODBC module > > and Oramod (which I can find nothing for - only patches?) > > Have you tried the ODBC binary that comes with PythonWin? > > > nothing seems to be designed for a windows environment. > > None of our modules are "designed" for windows. We use the same sources > on windows and Unix. > > Of course, you need a Windows-specific make file. Do you know > how to make one of these? > > > Do I really > > have to take the c code and the Python documentation and figure it all > > out myself -(not being much of a windows person). > > Not all of it. > > > Someone out there > > please give me help and guidance and if you have built a DBI interface > > to Oracle on windows please share your knowledge and experiences. > > If someone has successfully built the oracle module on > windows and is willing to share their binary, I'd be happy to > include it on out website. > > Jim > > -- > Jim Fulton mailto:jim@digicool.com > Technical Director (540) 371-6909 Python Powered! > Digital Creattions http://www.digicool.com http://www.python.org << File: Card for Victoria White >> _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Mon Jan 19 11:18:34 1998 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Mon, 19 Jan 1998 12:18:34 +0100 Subject: [DB-SIG] Oracle interface for Windows/NT References: <69D8143E230DD111B1D40000F848584001E53F44@ED> Message-ID: <34C3368A.6E7F6DC0@uni-duesseldorf.de> Greg Stein (Exchange) wrote: > > The ODBC module has been used extensively against Oracle databases, > including the use of dates and raw values. It was quite capable and had > everything needed. It is certainly more straightforward than trying to > use oracledb on NT, which I seriously doubt anybody has done, which > means that you'd be working with something even less stable than the > ODBC module. I believe mxODBC was intended for Unix platforms. Since it > uses the same interface as the win32 ODBC module, I don't see that it > would actually provide any additional benefit, and it, too, has > certainly been used less than the win32 ODBC module. One thing to note: the ODBC module that comes with Mark Hammonds PythonWin uses different date/time formats than mxODBC and does not yet provide catalog functions. In case you want to switch to mxODBC at a later point, you should use the dbi-interface in your apps. If you need to handle dates before 1.1.70 then you don't really have an option: if you're lucky (I can't tell, since I am not using PythonWin) and the time routines in Python also handle negative values correctly, the time values provide a range from 1901-2038. If not... Maybe Bill (or someone else) will find some time and incorporate the date/time types into the Win ODBC module too. Version 1.0 should be out in a month or so. The interface is stabilizing now. BTW: In case you get mxODBC to compile under Windows NT/95, please give me feeback about it (and any changes that you had to make). I don't want to compete against the win32 ODBC module, but I would like to make it as portable as possible. If someone turns it into a win32 DLL I would happily make that DLL available on starship. -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From gstein@exchange.microsoft.com Tue Jan 20 00:09:09 1998 From: gstein@exchange.microsoft.com (Greg Stein (Exchange)) Date: Mon, 19 Jan 1998 16:09:09 -0800 Subject: [DB-SIG] Oracle interface for Windows/NT Message-ID: <69D8143E230DD111B1D40000F848584001E53F50@ED> Good point, but let's also be clear that all of the existing DB-API modules use a consistent date/time mechanism: the unix time_t values (the integers returned by the time module). mxODBC is the "odd man out" in this context (in terms of its date/time handling, and the API extensions for catalog handling). That said, Marc is doing some good work to introducing a good date/time system for use by DB-API and Python in general. It looks like that new system will be incorporated into DB-API 1.1. -g -----Original Message----- From: M.-A. Lemburg [SMTP:lemburg@uni-duesseldorf.de] Sent: Monday, January 19, 1998 3:19 AM To: DB-SIG @ Python.org Subject: Re: [DB-SIG] Oracle interface for Windows/NT Greg Stein (Exchange) wrote: > > The ODBC module has been used extensively against Oracle databases, > including the use of dates and raw values. It was quite capable and had > everything needed. It is certainly more straightforward than trying to > use oracledb on NT, which I seriously doubt anybody has done, which > means that you'd be working with something even less stable than the > ODBC module. I believe mxODBC was intended for Unix platforms. Since it > uses the same interface as the win32 ODBC module, I don't see that it > would actually provide any additional benefit, and it, too, has > certainly been used less than the win32 ODBC module. One thing to note: the ODBC module that comes with Mark Hammonds PythonWin uses different date/time formats than mxODBC and does not yet provide catalog functions. In case you want to switch to mxODBC at a later point, you should use the dbi-interface in your apps. If you need to handle dates before 1.1.70 then you don't really have an option: if you're lucky (I can't tell, since I am not using PythonWin) and the time routines in Python also handle negative values correctly, the time values provide a range from 1901-2038. If not... Maybe Bill (or someone else) will find some time and incorporate the date/time types into the Win ODBC module too. Version 1.0 should be out in a month or so. The interface is stabilizing now. BTW: In case you get mxODBC to compile under Windows NT/95, please give me feeback about it (and any changes that you had to make). I don't want to compete against the win32 ODBC module, but I would like to make it as portable as possible. If someone turns it into a win32 DLL I would happily make that DLL available on starship. -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From jeremy@CNRI.Reston.Va.US Tue Jan 20 16:16:47 1998 From: jeremy@CNRI.Reston.Va.US (Jeremy Hylton) Date: Tue, 20 Jan 1998 11:16:47 -0500 Subject: [DB-SIG] which free database to use (and a few other questions) Message-ID: <199801201616.LAA21814@bitdiddle.Reston.Va.US> I'm looking for some advice on which database (and which database module) to use. I need a free database for several data collection/analysis projects, including TCP packet trace and HTTP server log analysis. A typical data set will be 50-100 MB. It looks like I can choose between miniSQL and MySQL, but I don't how good either product is. Can anyone recommend one over the other? I've spent an hour or two looking at miniSQL and it seems to provide adequate functionality (but I don't feel like I have a particularly informed decision). I'm also curious about the state of the Python modules for each of these databases. The miniSQL module doesn't conform to the DB API. Is this a problem? It looks like it would be easy enough to use the mSQL C library to implement an extension module. (But the fact that it looks pretty easy makes we wonder why no one else has? Perhaps there are some problems with mSQL...) I started looking at the MySQL module and stopped right away; the copyright notice is downright scary: "Note that any product, process or technology described in this software may be the subject of other Intellectual Property rights reserved by FGA bitart and are not licensed hereunder." Doesn't sound like free software to me. On the other hand, maybe MySQL also has a good C library that would make it easy to do a new extension module. Any thoughts? Finally, a question about the API itself. The spec. document on python.org says: >This specification document was last updated on: April 9, 1996. It >will be known as Version 1.0 of this specification. > >Note: The ODBC module implements a newer version of this >specification. Some additional error types were added to DBI. A spec >update is due. Should I be worried about this? The note about an update being due (apparently 9 months ago) makes me think the pages aren't being maintained. Has an update been produced? How substantial a change is it? Thanks, Jeremy -- Jeremy Hylton jeremy@cnri.reston.va.us _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From jeremy@CNRI.Reston.Va.US Tue Jan 20 16:16:47 1998 From: jeremy@CNRI.Reston.Va.US (Jeremy Hylton) Date: Tue, 20 Jan 1998 11:16:47 -0500 Subject: [DB-SIG] which free database to use (and a few other questions) Message-ID: <199801201616.LAA21814@bitdiddle.Reston.Va.US> I'm looking for some advice on which database (and which database module) to use. I need a free database for several data collection/analysis projects, including TCP packet trace and HTTP server log analysis. A typical data set will be 50-100 MB. It looks like I can choose between miniSQL and MySQL, but I don't how good either product is. Can anyone recommend one over the other? I've spent an hour or two looking at miniSQL and it seems to provide adequate functionality (but I don't feel like I have a particularly informed decision). I'm also curious about the state of the Python modules for each of these databases. The miniSQL module doesn't conform to the DB API. Is this a problem? It looks like it would be easy enough to use the mSQL C library to implement an extension module. (But the fact that it looks pretty easy makes we wonder why no one else has? Perhaps there are some problems with mSQL...) I started looking at the MySQL module and stopped right away; the copyright notice is downright scary: "Note that any product, process or technology described in this software may be the subject of other Intellectual Property rights reserved by FGA bitart and are not licensed hereunder." Doesn't sound like free software to me. On the other hand, maybe MySQL also has a good C library that would make it easy to do a new extension module. Any thoughts? Finally, a question about the API itself. The spec. document on python.org says: >This specification document was last updated on: April 9, 1996. It >will be known as Version 1.0 of this specification. > >Note: The ODBC module implements a newer version of this >specification. Some additional error types were added to DBI. A spec >update is due. Should I be worried about this? The note about an update being due (apparently 9 months ago) makes me think the pages aren't being maintained. Has an update been produced? How substantial a change is it? Thanks, Jeremy -- Jeremy Hylton jeremy@cnri.reston.va.us _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From Anthony Baxter Tue Jan 20 17:24:28 1998 From: Anthony Baxter (Anthony Baxter) Date: Wed, 21 Jan 1998 04:24:28 +1100 Subject: [DB-SIG] which free database to use (and a few other questions) In-Reply-To: Your message of "Tue, 20 Jan 1998 11:16:47 CDT." <199801201616.LAA21814@bitdiddle.Reston.Va.US> Message-ID: <199801201724.EAA04814@shara.off.connect.com.au> >>> Jeremy Hylton wrote > I'm also curious about the state of the Python modules for each of > these databases. The miniSQL module doesn't conform to the DB API. > Is this a problem? It looks like it would be easy enough to use the > mSQL C library to implement an extension module. (But the fact that > it looks pretty easy makes we wonder why no one else has? Perhaps > there are some problems with mSQL...) I did the original mSQL interface back in the dim dark days of mSQL 0.x. In the last couple of years, I've had no reason at all to use it, so I haven't DB-SIG'd the API. In the intervening time, at least a couple of other people have released enhanced versions of the mSQL module, but the original API is still there. I'd _love_ for someone to take the msql C API and write a new interface that's DB-SIG compliant - I still get mail asking about the mSQL module. As far as mSQL vs. mySQL; well, we use mySQL internally for anything where we can't use the Oracle databases - we used to use mSQL 1.x, but it's a total and utter Pig From Hell when your data gets up past 1 megabyte or so. Bambi has made a lot of improvements to 2.x, and I'm sure it's much better. (I have to say that, in case Bambi reads this and hits me next time he's in our Melbourne office :) Try both, see what works for you. If you wrote a DB-SIG compliant mSQL interface first, swapping between them would be easy. :) Anthony _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From caryc@shore.net Tue Jan 20 18:23:47 1998 From: caryc@shore.net (Cary Collett) Date: Tue, 20 Jan 1998 13:23:47 -0500 (EST) Subject: [DB-SIG] which free database to use (and a few other questions) In-Reply-To: <199801201616.LAA21814@bitdiddle.Reston.Va.US> from "Jeremy Hylton" at Jan 20, 98 11:16:47 am Message-ID: <199801201823.NAA19426@shell2.shore.net> > > I'm looking for some advice on which database (and which database > module) to use. I need a free database for several data > collection/analysis projects, including TCP packet trace and HTTP > server log analysis. A typical data set will be 50-100 MB. > > It looks like I can choose between miniSQL and MySQL, but I don't how > good either product is. Can anyone recommend one over the other? > I've spent an hour or two looking at miniSQL and it seems to provide > adequate functionality (but I don't feel like I have a particularly > informed decision). >From a feature and performance standpoint, MySQL beats mSQL hands down. I started using mSQL and later moved to MySQL and have been much happier. I think the user community for MySQL is more active as well, but I haven't really kept up with mSQL, so who knows. > > I'm also curious about the state of the Python modules for each of > these databases. The miniSQL module doesn't conform to the DB API. > Is this a problem? It looks like it would be easy enough to use the > mSQL C library to implement an extension module. (But the fact that > it looks pretty easy makes we wonder why no one else has? Perhaps > there are some problems with mSQL...) > > I started looking at the MySQL module and stopped right away; the > copyright notice is downright scary: "Note that any product, process > or technology described in this software may be the subject of other > Intellectual Property rights reserved by FGA bitart and are not > licensed hereunder." Doesn't sound like free software to me. > On the other hand, maybe MySQL also has a good C library that would > make it easy to do a new extension module. Any thoughts? You could also use ODBC to talk to MySQL if you're using Pythonwin. MySQL's C library is very similar to mSQL's and the MySQL module is based off of the mSQL module for this reason. IANACP (I am not a C programmer), but the API looks perfectly reasonable to me. Cary _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From aaron_watters@classic.msn.com Wed Jan 21 20:52:33 1998 From: aaron_watters@classic.msn.com (aaron watters) Date: Wed, 21 Jan 98 20:52:33 UT Subject: [DB-SIG] which free database to use (and a few other questions) Message-ID: I betcha you folks knew this was coming, dincha? You could also use gadfly: pure python sql. I don't know about how the performance would compare. I'm pleased with its performance myself, especially if you install kjbuckets. One problem: it's 100% in memory at present so you'd need lots of RAM and huge swap files (500M) But that's perfectly doable (also you'd best use kjbuckets, since it uses memory better). Realistically, even if you had Oracle you'd probably want to preprocess-extract the data first, if possible. 100MB is pretty huge. Anything is likely to be very slow. Alternatively you could subclass the "Relation0" class to read from disk in some cases. Easily done, actually, but I don't know how to hook such a thing into SQL syntax nicely... If you want to play with it I'd be happy to help (at least a bit). Alternatively, you could punt on sql and "home grow" your indices and queries in Python. Maybe using bplustree.py. http://www.pythonpros.com/arw Just a thought. New release always rsn. ;c) -- Aaron Watters -----Original Message----- From: owner-db-sig@python.org On Behalf Of Cary Collett Sent: Tuesday, January 20, 1998 1:24 PM To: jeremy@CNRI.Reston.Va.US Cc: db-sig@python.org Subject: Re: [DB-SIG] which free database to use (and a few other questions) > > I'm looking for some advice on which database (and which database > module) to use. I need a free database for several data > collection/analysis projects, including TCP packet trace and HTTP > server log analysis. A typical data set will be 50-100 MB. > > It looks like I can choose between miniSQL and MySQL, but I don't how > good either product is. Can anyone recommend one over the other? > I've spent an hour or two looking at miniSQL and it seems to provide > adequate functionality (but I don't feel like I have a particularly > informed decision). >From a feature and performance standpoint, MySQL beats mSQL hands down. I started using mSQL and later moved to MySQL and have been much happier. I think the user community for MySQL is more active as well, but I haven't really kept up with mSQL, so who knows. > > I'm also curious about the state of the Python modules for each of > these databases. The miniSQL module doesn't conform to the DB API. > Is this a problem? It looks like it would be easy enough to use the > mSQL C library to implement an extension module. (But the fact that > it looks pretty easy makes we wonder why no one else has? Perhaps > there are some problems with mSQL...) > > I started looking at the MySQL module and stopped right away; the > copyright notice is downright scary: "Note that any product, process > or technology described in this software may be the subject of other > Intellectual Property rights reserved by FGA bitart and are not > licensed hereunder." Doesn't sound like free software to me. > On the other hand, maybe MySQL also has a good C library that would > make it easy to do a new extension module. Any thoughts? You could also use ODBC to talk to MySQL if you're using Pythonwin. MySQL's C library is very similar to mSQL's and the MySQL module is based off of the mSQL module for this reason. IANACP (I am not a C programmer), but the API looks perfectly reasonable to me. Cary _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From 0rKJGiY50@stak1ed.net Thu Jan 22 11:05:39 1998 From: 0rKJGiY50@stak1ed.net (0rKJGiY50@stak1ed.net) Date: 22 Jan 98 11:05:39 PM Subject: [DB-SIG] Are You Happy? Message-ID: <4p92Hb7V8sIfW3p75s> There is brilliant information available to you, that will enable you to fully understand yourself and everybody else. This knowledge can benefit you tremendously in many ways. It can help you to get the very best out of your career, or discover your most suitable new career, and of course being happy at work, really improves the finances. It can also really enhance your love life. If you're in a relationship, it works great, because you are able to fully understand your own and your partner's emotions and motivations. If you're not, you will know exactly what you want from your perfect mate and what they will find attractive about you. Another big advantage to becoming balanced and happy is that good health runs hand in hand. Take a closer look two free pages of information at: http://www.po9.com _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Sun Jan 25 12:37:50 1998 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Sun, 25 Jan 1998 13:37:50 +0100 Subject: [DB-SIG] ANN: DateTime package version 0.6 Message-ID: <34CB321E.763F3C04@uni-duesseldorf.de> The DateTime package provides two new types that allow date/time storing, arithmetic and formatting -- extending the date range of the Unix time values 1970-2038 (seconds since 1.1.1970) to the range 1.1.0001 - >1.1.1000000, making Python year 2038 safe :-) After some changes to the interface (proposed by Greg Stein), bug fixes and a change in packaging, the module will enter the stabilization phase with this release. Version 1.0 is expected to be the "final" release. Please have a look and tell me what you think: http://starship.skyport.net/~lemburg/mxDateTime.html If you want to directly jump to the list of changes, use: http://starship.skyport.net/~lemburg/mxDateTime.html#History -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From esikes@anet-dfw.com Mon Jan 26 03:51:17 1998 From: esikes@anet-dfw.com (esikes@anet-dfw.com) Date: Sun, 25 Jan 1998 21:51:17 -0600 (CST) Subject: [DB-SIG] Home Bussiness Message-ID: We understand that you are interested in, or are already involved in marketing. We are searching for people to get into the highest paying plan in the world. Contact me for all the details. I have 28yrs. in the business world. 1-(972) 557-0955 Ed Sikes You may also visit my website at: http://www.admaxsilver.com/sikes/ **(( You have recieved this message because you have visited one of our business opportunity sites in the past. If you have recieved this message in error or simply wish to be removed from our list please reply with the word "remove" in the subject header. We apologize for any inconvience if we have sent this to you in error.))** _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From Tod Olson Mon Jan 26 18:00:26 1998 From: Tod Olson (Tod Olson) Date: Mon, 26 Jan 1998 12:00:26 -0600 Subject: [DB-SIG] Database API clarifications Message-ID: <199801261800.MAA11267@stone.lib.uchicago.edu> I'm working on a Sybase interface for Python. The ones that exist do not appear to permit sufficient low-level access for my needs, so I'm implementing a low-level interface as a wrapper around Open Client and will build a database-API-compliant interface on top of that. Sybase permits one to issue a command that will generate multiple result sets. The database-API does not directly address this possibility. How should the fetch*() functions distinguish to the Python programmer the difference between the end of the current result set and the end of all data returned by the command? Under the current database-API, the programmer could loop over any of the fetch*() functions, have None signal end of all results, and look for a change in description to signal a new result set. (Personal bias: fetchmany() and fetchall() should only return rows from one result set on any invocation.) But this is potentially unreliable, as two result sets might have the same descriptions. Another question: once any of fetch*() returns None, should they continue to return None until the next command is sent, or can they signal an error after returning None? I'm interested in these fetch*() details because I am implementing them (so for as possible) directly in my low-level interface. Anyone else running into these issues? Anyone else interested in lower level access to Sybase? Thanks. Tod A. Olson "How do you know I'm mad?" said Alice. ta-olson@uchicago.edu "If you weren't mad, you wouldn't have The University of Chicago Library come here," said the Cat. _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From billtut@microsoft.com Mon Jan 26 19:53:30 1998 From: billtut@microsoft.com (Bill Tutt) Date: Mon, 26 Jan 1998 11:53:30 -0800 Subject: [DB-SIG] Database API clarifications Message-ID: <4D0A23B3F74DD111ACCD00805F31D81045380C@red-msg-50.dns.microsoft.com> Generally the way to do this is just to have a seperate getNextResult() API call that you call when your first result set fetch*() calls return None. Bill More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason ---including blind stupidity. > Python: the power of simplicity > Perl: the power of obscurity > > > > -----Original Message----- > From: Tod Olson [SMTP:tao@stone.lib.uchicago.edu] > Sent: Monday, January 26, 1998 10:00 AM > To: db-sig@python.org > Subject: [DB-SIG] Database API clarifications > > I'm working on a Sybase interface for Python. The ones that exist do > not appear to permit sufficient low-level access for my needs, so I'm > implementing a low-level interface as a wrapper around Open Client and > will build a database-API-compliant interface on top of that. > > Sybase permits one to issue a command that will generate multiple > result sets. The database-API does not directly address this > possibility. How should the fetch*() functions distinguish to the > Python programmer the difference between the end of the current result > set and the end of all data returned by the command? > > Under the current database-API, the programmer could loop over any of > the fetch*() functions, have None signal end of all results, and look > for a change in description to signal a new result set. (Personal > bias: fetchmany() and fetchall() should only return rows from one > result set on any invocation.) But this is potentially unreliable, as > two result sets might have the same descriptions. > > Another question: once any of fetch*() returns None, should they > continue to return None until the next command is sent, or can they > signal an error after returning None? > > I'm interested in these fetch*() details because I am implementing > them (so for as possible) directly in my low-level interface. > > Anyone else running into these issues? Anyone else interested in > lower level access to Sybase? > > Thanks. > > Tod A. Olson "How do you know I'm mad?" said Alice. > ta-olson@uchicago.edu "If you weren't mad, you wouldn't have > The University of Chicago Library come here," said the Cat. > > _______________ > DB-SIG - SIG on Tabular Databases in Python > > send messages to: db-sig@python.org > administrivia to: db-sig-request@python.org > _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From Tod Olson Mon Jan 26 21:53:24 1998 From: Tod Olson (Tod Olson) Date: Mon, 26 Jan 1998 15:53:24 -0600 Subject: [DB-SIG] Database API clarifications In-Reply-To: Your message of "Mon, 26 Jan 1998 11:53:30 -0800" References: <4D0A23B3F74DD111ACCD00805F31D81045380C@red-msg-50.dns.microsoft.com> Message-ID: <199801262153.PAA19421@stone.lib.uchicago.edu> >>>>> "B" == Bill Tutt writes: B> Generally the way to do this is just to have a seperate B> getNextResult() API call that you call when your first result set B> fetch*() calls return None. So the next question to the SIG: should this mechanism (or some other) for handling multiple result sets be included in the database API? Tod A. Olson "How do you know I'm mad?" said Alice. ta-olson@uchicago.edu "If you weren't mad, you wouldn't have The University of Chicago Library come here," said the Cat. _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From cary@ratatosk.org Tue Jan 27 19:41:27 1998 From: cary@ratatosk.org (Cary Collett) Date: Tue, 27 Jan 1998 14:41:27 -0500 Subject: [DB-SIG] OracleDB and Python 1.5 Message-ID: <19980127144127.57716@ratatosk.org> I'm going to be lazy here and ask instead of compiling and trying this... Does anyone know if the oracledb-0.1.3 module works under Python 1.5? Cary -- Cary Collett cary@ratatosk.org To me, boxing is like ballet, except there's no dancing, no choreography and the dancers hit eachother. _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Wed Jan 28 15:15:11 1998 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Wed, 28 Jan 1998 16:15:11 +0100 Subject: [DB-SIG] Database API clarifications References: <4D0A23B3F74DD111ACCD00805F31D81045380C@red-msg-50.dns.microsoft.com> <199801262153.PAA19421@stone.lib.uchicago.edu> Message-ID: <34CF4B7F.5BA48494@uni-duesseldorf.de> Tod Olson wrote: > > >>>>> "B" == Bill Tutt writes: > > B> Generally the way to do this is just to have a seperate > B> getNextResult() API call that you call when your first result set > B> fetch*() calls return None. > > So the next question to the SIG: should this mechanism (or some other) > for handling multiple result sets be included in the database API? > Could you explain how you define multiple result sets with one SQL statement ? I'm not sure whether a cursor method is the right thing to add. Also, most DBs probably don't support this feature, so it should be optional from the APIs point of view. -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From cjr@euronet.nl Thu Jan 29 11:52:02 1998 From: cjr@euronet.nl (cjr@euronet.nl) Date: Thu, 29 Jan 1998 11:52:02 +0000 (WET) Subject: [DB-SIG] OracleDB and Python 1.5 In-Reply-To: <19980127144127.57716@ratatosk.org> from "Cary Collett" at Jan 27, 98 02:41:27 pm Message-ID: <199801291152.LAA15133@axiom.euronet.nl> > I'm going to be lazy here and ask instead of compiling and trying this... > > Does anyone know if the oracledb-0.1.3 module works under Python 1.5? Not having seen other answers: I compiled it on Solaris for Oracle-7.3.2.2. I didn't get further than importing the resulting module and doing a dir(oracledb) on it, that is, I didn't have any test code handy. Well, getting that far is already pretty promising. cjr _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From sbi@acse.be" I did compile it on Solaris with Oracle 7.3.3. The following works... >>> import oracledb >>> o = oracledb.oracledb("/") >>> c = o.cursor() >>> c.execute("select * from tab") >>> c.fetchall() ... but I did not try it further. -sbi On Thursday, January 29, 1998 9:50 AM, Cary Collett [SMTP:cary@ratatosk.org] wrote: > > I'm going to be lazy here and ask instead of compiling and trying this... > > Does anyone know if the oracledb-0.1.3 module works under Python 1.5? > > Cary > > -- > Cary Collett cary@ratatosk.org > > To me, boxing is like ballet, except there's no dancing, no choreography > and the dancers hit eachother. > > _______________ > DB-SIG - SIG on Tabular Databases in Python > > send messages to: db-sig@python.org > administrivia to: db-sig-request@python.org > _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From ted_horst@swissbank.com Thu Jan 29 15:20:08 1998 From: ted_horst@swissbank.com (Ted Horst) Date: Thu, 29 Jan 98 09:20:08 -0600 Subject: [DB-SIG] Database API clarifications In-Reply-To: <34CF4B7F.5BA48494@uni-duesseldorf.de> References: <4D0A23B3F74DD111ACCD00805F31D81045380C@red-msg-50.dns.microsoft.com> <199801262153.PAA19421@stone.lib.uchicago.edu> <34CF4B7F.5BA48494@uni-duesseldorf.de> Message-ID: <9801291520.AA00683@ch1d162nwk> Multiple result sets are commonly returned from stored procedures, but you can also send multiple select statements at one time. My noncompliant sybase module always returns a list of result sets (although there is usually only only item in the list). Ted Horst (not speaking for any current or future Swiss Bank) You wrote: > Tod Olson wrote: > > > > >>>>> "B" == Bill Tutt writes: > > > > B> Generally the way to do this is just to have a seperate > > B> getNextResult() API call that you call when your first result set > > B> fetch*() calls return None. > > > > So the next question to the SIG: should this mechanism (or some other) > > for handling multiple result sets be included in the database API? > > > > Could you explain how you define multiple result sets with one > SQL statement ? I'm not sure whether a cursor method is the right > thing to add. Also, most DBs probably don't support this feature, > so it should be optional from the APIs point of view. > > -- > Marc-Andre Lemburg > > > _______________ > DB-SIG - SIG on Tabular Databases in Python > > send messages to: db-sig@python.org > administrivia to: db-sig-request@python.org > _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From thomas.marsh@tivoli.com Thu Jan 29 15:58:53 1998 From: thomas.marsh@tivoli.com (Thomas Marsh) Date: Thu, 29 Jan 1998 09:58:53 -0600 Subject: [DB-SIG] Database API clarifications References: <4D0A23B3F74DD111ACCD00805F31D81045380C@red-msg-50.dns.microsoft.com> <199801262153.PAA19421@stone.lib.uchicago.edu> <34CF4B7F.5BA48494@uni-duesseldorf.de> Message-ID: <34D0A73D.2D1527B9@tivoli.com> M.-A. Lemburg wrote: > > Tod Olson wrote: > > > > >>>>> "B" == Bill Tutt writes: > > > > B> Generally the way to do this is just to have a seperate > > B> getNextResult() API call that you call when your first result set > > B> fetch*() calls return None. > > > > So the next question to the SIG: should this mechanism (or some other) > > for handling multiple result sets be included in the database API? > > > > Could you explain how you define multiple result sets with one > SQL statement ? I'm not sure whether a cursor method is the right > thing to add. Also, most DBs probably don't support this feature, > so it should be optional from the APIs point of view. Any database that supports compute clauses should return multiple result sets. Sybase, for instance, does this. --thomas -- Thomas Marsh thomas.marsh@tivoli.com Tivoli Systems, Inc. (512) 436 8643 _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Fri Jan 30 16:36:52 1998 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Fri, 30 Jan 1998 17:36:52 +0100 Subject: [DB-SIG] Database API clarifications References: <4D0A23B3F74DD111ACCD00805F31D81045380C@red-msg-50.dns.microsoft.com> <199801262153.PAA19421@stone.lib.uchicago.edu> <34CF4B7F.5BA48494@uni-duesseldorf.de> <34D0A73D.2D1527B9@tivoli.com> Message-ID: <34D201A4.36C39111@uni-duesseldorf.de> Thomas Marsh wrote: > > M.-A. Lemburg wrote: > > > [...] > > Could you explain how you define multiple result sets with one > > SQL statement ? I'm not sure whether a cursor method is the right > > thing to add. Also, most DBs probably don't support this feature, > > so it should be optional from the APIs point of view. > > Any database that supports compute clauses should return multiple result > sets. Sybase, for instance, does this. Ok, I see. Well then a method cursor.nextset() should go into the API. With the same semantics that Bill proposed: return 1 if there are more sets and organize for the next fetch* calls to return rows from the next set; return 0 otherwise. Interface packages not providing this feature should always return 0. Is that ok ? I'll add to my API 1.1. draft then. -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From billtut@microsoft.com Fri Jan 30 23:35:19 1998 From: billtut@microsoft.com (Bill Tutt) Date: Fri, 30 Jan 1998 15:35:19 -0800 Subject: [DB-SIG] Database API clarifications Message-ID: <4D0A23B3F74DD111ACCD00805F31D81045382A@red-msg-50.dns.microsoft.com> > -----Original Message----- > From: M.-A. Lemburg [SMTP:lemburg@uni-duesseldorf.de] > Sent: Friday, January 30, 1998 8:37 AM > To: DB-SIG @ Python.org > Subject: Re: [DB-SIG] Database API clarifications > > > Ok, I see. Well then a method cursor.nextset() should go into the > API. With the same semantics that Bill proposed: > > return 1 if there are more sets and organize for the > next fetch* calls to return rows from the next set; > return 0 otherwise. > > Interface packages not providing this feature should always > return 0. > > Is that ok ? I'll add to my API 1.1. draft then. > Well, close, but preferably return None instead of 0, this is Python after all. :) Bill _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Sat Jan 31 10:01:46 1998 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Sat, 31 Jan 1998 11:01:46 +0100 Subject: [DB-SIG] Database API clarifications References: <4D0A23B3F74DD111ACCD00805F31D81045382A@red-msg-50.dns.microsoft.com> Message-ID: <34D2F68A.50582178@uni-duesseldorf.de> Bill Tutt wrote: > > > me: > > Is that ok ? I'll add it to my API 1.1. draft then. > > > Well, close, but preferably return None instead of 0, this is Python after > all. :) Right -- has a better sound to it :-) -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________