From Tod Olson Wed Jul 1 16:49:49 1998 From: Tod Olson (Tod Olson) Date: Wed, 01 Jul 1998 10:49:49 -0500 Subject: [DB-SIG] DB API 1.1a3 In-Reply-To: Your message of "Tue, 23 Jun 1998 15:45:21 +0200" References: <358FB171.1F88E69A@lemburg.com> Message-ID: <199807011549.KAA12495@stone.lib.uchicago.edu> >>>>> "M" == M -A Lemburg writes: M> I've uploaded a new edited version of the API 1.1 specification. It M> includes most of the things and modifications we have discussed in M> the past weeks (I probably forgot some): M> http://starship.skyport.net/~lemburg/DatabaseAPI-1.1.html M> Comments ? I notice that 1.1 no longer requires Connection objects to implement all Cursor object attributes and methods. Any reason? I would like the requirement to remain. 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. From mal@lemburg.com Wed Jul 1 21:29:51 1998 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 01 Jul 1998 22:29:51 +0200 Subject: [DB-SIG] DB API 1.1a3 References: <358FB171.1F88E69A@lemburg.com> <199807011549.KAA12495@stone.lib.uchicago.edu> Message-ID: <359A9C3F.32195F0E@lemburg.com> Tod Olson wrote: > > >>>>> "M" == M -A Lemburg writes: > > M> I've uploaded a new edited version of the API 1.1 specification. It > M> includes most of the things and modifications we have discussed in > M> the past weeks (I probably forgot some): > > M> http://starship.skyport.net/~lemburg/DatabaseAPI-1.1.html > > M> Comments ? > > I notice that 1.1 no longer requires Connection objects to implement > all Cursor object attributes and methods. Any reason? I would like > the requirement to remain. Is anybody using this ? I think it's a better idea to provide a dummy cursor object than having connection objects give access to cursor methods and attributes: it makes porting applications a lot easier. Database interfaces which do not really support cursors could raise an exception if more than one cursor is being created. But that's of course just my POV. -- Marc-Andre Lemburg Y2000: 548 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From Tod Olson Wed Jul 1 22:32:52 1998 From: Tod Olson (Tod Olson) Date: Wed, 01 Jul 1998 16:32:52 -0500 Subject: [DB-SIG] DB API 1.1a3 In-Reply-To: Your message of "Wed, 01 Jul 1998 22:29:51 +0200" References: <359A9C3F.32195F0E@lemburg.com> Message-ID: <199807012132.QAA25496@stone.lib.uchicago.edu> >>>>> "M" == M -A Lemburg writes: M> Tod Olson wrote: >> >> I notice that 1.1 no longer requires Connection objects to implement >> all Cursor object attributes and methods. Any reason? I would like >> the requirement to remain. M> Is anybody using this ? I think it's a better idea to provide a M> dummy cursor object than having connection objects give access to M> cursor methods and attributes: it makes porting applications a lot M> easier. Database interfaces which do not really support cursors M> could raise an exception if more than one cursor is being created. M> But that's of course just my POV. But what about databases where connections and cursors really are different? That is, in Sybase you can submit SQL through either a connection or a cursor, and that implies some meaningful difference to the server. Eg. some things are legal in a connection that aren't in a cursor (don't ask for specifics, but we just saw an example two days ago). Of course if no other database does this sort of thing, it probably doesn't need to be reflected in the standard. 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. From jim.fulton@Digicool.com Wed Jul 1 22:32:06 1998 From: jim.fulton@Digicool.com (Jim Fulton) Date: Wed, 01 Jul 1998 17:32:06 -0400 Subject: [DB-SIG] DB API 1.1a3 References: <358FB171.1F88E69A@lemburg.com> <199807011549.KAA12495@stone.lib.uchicago.edu> <359A9C3F.32195F0E@lemburg.com> Message-ID: <359AAAD6.5572@digicool.com> M.-A. Lemburg wrote: > > Tod Olson wrote: > > > > >>>>> "M" == M -A Lemburg writes: > > > > M> I've uploaded a new edited version of the API 1.1 specification. It > > M> includes most of the things and modifications we have discussed in > > M> the past weeks (I probably forgot some): > > > > M> http://starship.skyport.net/~lemburg/DatabaseAPI-1.1.html > > > > M> Comments ? > > > > I notice that 1.1 no longer requires Connection objects to implement > > all Cursor object attributes and methods. Any reason? I would like > > the requirement to remain. > > Is anybody using this ? I find it very annoying to have to support this. It is crudifying a DBI module I'm working on. Ick. > I think it's a better idea to provide a > dummy cursor object than having connection objects give access to > cursor methods and attributes: it makes porting applications a lot > easier. Database interfaces which do not really support cursors > could raise an exception if more than one cursor is being created. > But that's of course just my POV. I agree. (Actually, I don't like the DBI-API's exposed cursor interface, but given it, I agree. :) Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From pgodman@halcyon.com Wed Jul 1 23:05:12 1998 From: pgodman@halcyon.com (Peter Godman) Date: Wed, 1 Jul 1998 15:05:12 -0700 (PDT) Subject: [DB-SIG] DB API 1.1a3 In-Reply-To: <199807012132.QAA25496@stone.lib.uchicago.edu> Message-ID: On Wed, 1 Jul 1998, Tod Olson wrote: > >>>>> "M" == M -A Lemburg writes: > > M> Tod Olson wrote: > >> > >> I notice that 1.1 no longer requires Connection objects to implement > >> all Cursor object attributes and methods. Any reason? I would like > >> the requirement to remain. > > M> Is anybody using this ? I think it's a better idea to provide a > M> dummy cursor object than having connection objects give access to > M> cursor methods and attributes: it makes porting applications a lot > M> easier. Database interfaces which do not really support cursors > M> could raise an exception if more than one cursor is being created. > M> But that's of course just my POV. > > But what about databases where connections and cursors really are > different? That is, in Sybase you can submit SQL through either a > connection or a cursor, and that implies some meaningful difference to > the server. Eg. some things are legal in a connection that aren't in > a cursor (don't ask for specifics, but we just saw an example two days > ago). > > Of course if no other database does this sort of thing, it probably > doesn't need to be reflected in the standard. I feel it is important that it be in the standard, and would ask that if we want to get rid of one of the two interfaces, why not make it the cursor interface? One can alway implement cursors using language commands (and presumably many are done this way). Since Sybase supports library and language cursors, and they behave and perform in quite different ways, I'm happy that both interfaces exist because it means that both types of functionality can be provided in my Sybase module. Language cursors may still be created by the user at will through the connection interface. Without the connection interface in Sybase there would be no way for the user to express regular language commands, including language cursors (am I right in thinking this?), and without the cursor interface, it would be impossible to express library cursors, which are the only cursors which may be opened on the output of a stored procedure. This is useful functionality. Does anyone know what the other big advantages of client-side (library) cursors are? Honestly I don't remember the rest ;-) Which brings me to another point... I'm really getting out of touch with the database world now (it's been a whole six months). I've mentioned it before and had some responses, but now I think I really have to ask if anyone would like to take over maintenance of the Sybase module I wrote (still definitely not _the_ sybase module (plenty of competition for that title ;-)). I have no Sybase access still and not a lot of time, since I'm wrapped up in my job, and things RealAudio/RealVideo related. Well, to everyone out there, let me know if you're interested. Thanks, Peter Godman > > 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 maillist - DB-SIG@python.org > http://www.python.org/mailman/listinfo/db-sig > > From mal@lemburg.com Thu Jul 2 09:10:20 1998 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 02 Jul 1998 10:10:20 +0200 Subject: [DB-SIG] DB API 1.1a3 References: Message-ID: <359B406C.7D1B989D@lemburg.com> Peter Godman wrote: > > On Wed, 1 Jul 1998, Tod Olson wrote: > > > >>>>> "M" == M -A Lemburg writes: > > > > M> Tod Olson wrote: > > >> > > >> I notice that 1.1 no longer requires Connection objects to implement > > >> all Cursor object attributes and methods. Any reason? I would like > > >> the requirement to remain. > > > > M> Is anybody using this ? I think it's a better idea to provide a > > M> dummy cursor object than having connection objects give access to > > M> cursor methods and attributes: it makes porting applications a lot > > M> easier. Database interfaces which do not really support cursors > > M> could raise an exception if more than one cursor is being created. > > M> But that's of course just my POV. > > > > But what about databases where connections and cursors really are > > different? That is, in Sybase you can submit SQL through either a > > connection or a cursor, and that implies some meaningful difference to > > the server. Eg. some things are legal in a connection that aren't in > > a cursor (don't ask for specifics, but we just saw an example two days > > ago). > > > > Of course if no other database does this sort of thing, it probably > > doesn't need to be reflected in the standard. > > I feel it is important that it be in the standard, and would ask that if > we want to get rid of one of the two interfaces, why not make it the > cursor interface? No, this wouldn't make sense in the general case. Only Sybase seems to have a need for this feature, so dropping it from the standard spec wouldn't hurt much, because a) the sybase module may still implement these features on top of the API spec - it is no violation of the spec to *add* features b) you are not likely to find another database that exposes the the same semantics as the ones you both described, so portability is no issue c) you can always wrap connection objects with your own Python objects and these could then emulate the intended and expected behaviour -- Marc-Andre Lemburg Y2000: 547 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From skrishna@cisco.com Fri Jul 3 01:52:29 1998 From: skrishna@cisco.com (SRIDHAR KRISHNAN) Date: Thu, 2 Jul 1998 17:52:29 -0700 (PDT) Subject: [DB-SIG] mxODBC 0.8 Binary Available ? Message-ID: I downloaded mxODBC for Windows - however, the binary for mxODBC is not yet built. Does anybody have one built ? TIA, -- Sridhar From alexan@www.micex.com Fri Jul 3 07:14:54 1998 From: alexan@www.micex.com (Alexander Kuznetsov) Date: Fri, 03 Jul 1998 06:14:54 +0000 Subject: [DB-SIG] INTERBASEDB module available! Message-ID: <359C76DE.DCB5516@www.micex.com> Interbasedb is in reliable state now. Use it NOW! http://unicorn.micex.ru/users/alexan/interbasedb/ Developing in progress, so mail me your suggestions. -- Best regards. Alexander Kuznetsov. Mail me to alexan@misha.micex.com From alexan@www.micex.com Fri Jul 3 11:33:45 1998 From: alexan@www.micex.com (Alexander Kuznetsov) Date: Fri, 03 Jul 1998 10:33:45 +0000 Subject: [DB-SIG] Interbasedb 2.4 shipped Message-ID: <359CB389.39510117@www.micex.com> New version 2.4 is here http://unicorn.micex.ru/users/alexan/interbasedb/ Now it can pass transaction parameters to begin(). And connection object can -- Best regards. Alexander Kuznetsov. Mail me to alexan@misha.micex.com From harri.pasanen@trema.com Fri Jul 10 15:18:42 1998 From: harri.pasanen@trema.com (Harri Pasanen) Date: Fri, 10 Jul 1998 16:18:42 +0200 Subject: [DB-SIG] ctsybase module coredump Message-ID: <35A622C2.1D3942ED@trema.com> Howdy, It seems that if I don't read all the data from a cursor, but instead execute() another statement, the ctsybase module causes python to dump core. It does is at the point marked by <----, line 168 of ctsybase.c CS_RETCODE CS_PUBLIC PySybConnection_clientmsgcallback(CS_CONTEXT *context, CS_CONNECTION *connection, CS_CLIENTMSG *clientMsg) { PyObject * argument, *result; if (currentConnection->clientMsgCallback == Py_None) <--- dumps return CS_SUCCEED; Looking with gdb looks like currentConnection is NULL. What I'm trying to do is: To get a description of a table I have to fetch atleast one row. Provided on the type of the columns in the table has I may either proceed to do other query, or read the rest of the rows. Problem is, that if I proceed to do the other query without reading in all the results of my first query, I get the above core dump. Any suggestions or patches to ctsybase.c ? Thanks, Harri From pgodman@halcyon.com Fri Jul 10 18:21:43 1998 From: pgodman@halcyon.com (Peter Godman) Date: Fri, 10 Jul 1998 10:21:43 -0700 (PDT) Subject: [DB-SIG] ctsybase module coredump In-Reply-To: <35A622C2.1D3942ED@trema.com> Message-ID: On Fri, 10 Jul 1998, Harri Pasanen wrote: > Howdy, > > It seems that if I don't read all the data from a cursor, > but instead execute() another statement, the ctsybase module > causes python to dump core. > > > It does is at the point marked by <----, line 168 of ctsybase.c > > CS_RETCODE CS_PUBLIC > PySybConnection_clientmsgcallback(CS_CONTEXT *context, CS_CONNECTION > *connection, CS_CLIENTMSG *clientMsg) > { > PyObject * argument, *result; > if (currentConnection->clientMsgCallback == Py_None) <--- dumps > return CS_SUCCEED; > > > Looking with gdb looks like currentConnection is NULL. > > > What I'm trying to do is: > > To get a description of a table I have to fetch atleast one row. > Provided on the type of the columns in the table has I may > either proceed to do other query, or read the rest of the rows. > > Problem is, that if I proceed to do the other query without > reading in all the results of my first query, > I get the above core dump. > > > Any suggestions or patches to ctsybase.c ? > > Thanks, > > Harri Hi Harri! Here's a quick patch that I know will fix the immediate problem. Unfortunately I don't have the means to test it (anyone have a copy of Sybase 10 they'd like to donate?) change the line to if (!currentConnection || currentConnection->clientMsgCallback == Py_None) However, the fact that the inline error handler is being called indicates there's probably a client state error in the state machine, which means after you fix this, the command will return with an error (probably) (either that or an informational message). The problem immediately is that currentConnection is a static used for the sake of switching the sybase async error handler point to the right handler for the current connection at all times. Currently, I think we're at a point in the state machine where there is no connection. This is probably indicative of a serious problem. I'll be interested to see what happens when you make this change. Thanks, Pete > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://www.python.org/mailman/listinfo/db-sig > > From jim.fulton@Digicool.com Tue Jul 14 14:35:01 1998 From: jim.fulton@Digicool.com (Jim Fulton) Date: Tue, 14 Jul 1998 09:35:01 -0400 Subject: [DB-SIG] New home needed for oracledb Message-ID: <35AB5E85.58AC@digicool.com> Hi all, Some time ago, the copyright for the oracledb module was transfered to us so that we could make it available to the Python community. We've made minor enhancements to it and made it available in an "unsupported" way. Recently, we've developed an entirely new Oracle package from scratch. This new package has many advantages over the existing oracledb module. We've decided to make this new module available as a commercially supported product. We feel that we have to charge for the module and for support to cover the high cost for building and supporting it. Unfortunately, this puts us in an uncomfortable position wrt the oracledb module. I think it is a bad idea for us to distribute the old oracledb in a totally unsupported fashion while making another package available for sale. I'd like to transfer the stewardship and copyright for the oracledb module to someone else. Any volunteers? Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. From guido@CNRI.Reston.Va.US Tue Jul 14 14:53:26 1998 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Tue, 14 Jul 1998 09:53:26 -0400 Subject: [DB-SIG] New home needed for oracledb In-Reply-To: Your message of "Tue, 14 Jul 1998 09:35:01 EDT." <35AB5E85.58AC@digicool.com> References: <35AB5E85.58AC@digicool.com> Message-ID: <199807141353.JAA08787@eric.CNRI.Reston.Va.US> > I'd like to transfer the stewardship and copyright for the oracledb > module to someone else. CNRI could take it over and make it available from its website, but we'd be entirely dependent on others for its upkeep -- we don't know zit about Oracle, we don't have Oracle, so we wouldn't be able to do any testing or maintenance. Thus, we would be entirely dependent on others to supply us with patches. If someone else is at all interested, that would probably be a much better solution. (How about PPSI?) --Guido van Rossum (home page: http://www.python.org/~guido/) From Anthony Baxter Tue Jul 14 17:03:05 1998 From: Anthony Baxter (Anthony Baxter) Date: Wed, 15 Jul 1998 02:03:05 +1000 Subject: [DB-SIG] New home needed for oracledb In-Reply-To: Your message of "Tue, 14 Jul 1998 09:35:01 -0400." <35AB5E85.58AC@digicool.com> Message-ID: <199807141603.CAA14372@jambu.off.connect.com.au> >>> Jim Fulton wrote > Unfortunately, this puts us in an uncomfortable position wrt > the oracledb module. I think it is a bad idea for us to distribute > the old oracledb in a totally unsupported fashion while making another > package available for sale. > > I'd like to transfer the stewardship and copyright for the oracledb > module to someone else. I was actually hoping to get a new interim oracledb release out this week, but a mother-of-all-sinus-infections has intervened. From arb@connect.com.au Wed Jul 29 07:07:11 1998 From: arb@connect.com.au (Anthony Baxter) Date: Wed, 29 Jul 1998 16:07:11 +1000 Subject: [DB-SIG] continuing oracledb development. Message-ID: <199807290607.QAA27815@koro.off.connect.com.au> I sent out an announcement for oracledb 0.2pre1 to python-announce and c.l.p yesterday, and I'd just like to solicit some feedback on the build process. I _think_ that the autosetup.py script will build a working Setup file by itself, but I don't have access to very many OS / Oracle version combos. Could you take a few minutes to download it from http://alumni.dgs.monash.edu.au/~anthony/oracledb/, unpack it, then run autosetup.py make -f Makefile.pre.in boot make python -c "import oracledb" and check that it works for you (no unresolved symbols). If it works, could you let me know your OS/Oracle version combo? Right now, the oracledb module itself probably isn't suitable for production use, but I'm looking to fix this ASAP. Thanks for your help, Anthony From ccegongw@nus.edu.sg Wed Jul 29 13:09:09 1998 From: ccegongw@nus.edu.sg (Gong Wei) Date: Wed, 29 Jul 1998 20:09:09 +0800 Subject: [DB-SIG] SQL database for Python Message-ID: <35BF10E5.3C9DE6B7@nus.edu.sg> Hi all, I believe the question has been asked many many times, however, I couldn't find a good solution myself. So would like to know your opinion. Requirement: 1. Robust, never(seldom) crash. 2. allow multiple, concurrent access. There will be only 1 writer at any instance of time. 3. has some python interface which conforms to db-sig API specification. Pls comment, you help is much appreciated! P.S. It's much better if followup could be replied to my email. I just subscribed, don't know when it's going to take effect... Regards ====== Gong Wei From dfauser@amadeus.net Wed Jul 29 14:40:41 1998 From: dfauser@amadeus.net (dfauser@amadeus.net) Date: Wed, 29 Jul 1998 14:40:41 +0100 Subject: [DB-SIG] informixdb Message-ID: <41256650.004AC68E.00@mta.amadeus.net> Hello, I've got a question concerning the informix modul: I've downloaded the version 1.5.1 of python and the version 1.0.1 of the informix module. Both compile very well, but when I try to import the _informixdb module there is the followin error: ImportError: ld.so.1: python: fatal: relocation error: file /users/dfauser/python/lib/python1.5/_informixdb.so: symbol gl_destroystring: referenced symbol not found Do you have any idea why this happens ? Thank you for sending me a small answer if you know how to fix the problem Best Regard Dietmar From caryc@shore.net Wed Jul 29 14:18:52 1998 From: caryc@shore.net (Cary Collett) Date: Wed, 29 Jul 1998 09:18:52 -0400 Subject: [DB-SIG] SQL database for Python In-Reply-To: <35BF10E5.3C9DE6B7@nus.edu.sg>; from Gong Wei on Wed, Jul 29, 1998 at 08:09:09PM +0800 References: <35BF10E5.3C9DE6B7@nus.edu.sg> Message-ID: <19980729091852.A20806@shore.net> Gong, Sounds like you want MySQL. It is VERY VERY fast, multithreaded and has a DP API compliant interface. http://www.tcx.se for more info. MySQL is free for most uses (except bundling it and selling it, then you have to buy a license). You can also purchase support. It lacks some features like transactions and triggers, but you don't mention that you need them. If you want something free that has more features, but is slower you might want to check out PostgreSQL. I don't use and so I don't have the URL for it handy but a search at Yahoo should turn it up. Lastly, if you want to go commercial, but don't want to spend the money on Oracle, you could try Solid (http://www.solidtech.com/). Cary Gong Wei (ccegongw@nus.edu.sg) said: > Hi all, > > I believe the question has been asked many many times, however, I > couldn't find a good solution myself. So would like to know your > opinion. > > Requirement: > 1. Robust, never(seldom) crash. > 2. allow multiple, concurrent access. There will be only 1 writer at > any instance of time. > 3. has some python interface which conforms to db-sig API specification. > > Pls comment, you help is much appreciated! > > P.S. It's much better if followup could be replied to my email. I just > subscribed, don't know when it's going to take effect... > > Regards > ====== > Gong Wei > > -- Cary Collett cary@ratatosk.org To me, boxing is like ballet, except there's no dancing, no choreography and the dancers hit eachother. From A.M.INGRALDI@larc.nasa.gov Wed Jul 29 14:49:15 1998 From: A.M.INGRALDI@larc.nasa.gov (Anthony M. Ingraldi) Date: Wed, 29 Jul 1998 09:49:15 -0400 Subject: [DB-SIG] informixdb In-Reply-To: <41256650.004AC68E.00@mta.amadeus.net> Message-ID: >Both compile very well, but when I try to import the _informixdb module >there is the followin error: > >ImportError: ld.so.1: python: fatal: relocation error: file >/users/dfauser/python/lib/python1.5/_informixdb.so: >symbol gl_destroystring: referenced symbol not found > >Do you have any idea why this happens ? > I had a similar problem. I needed to make some changes to the informixdb Makefile in order to achieve a successfull import. The key change is on the LIBS definition line old definition: LIBS=-lasf -lsql -los -lgen new definition: LIBS=-lixsql -lixasf -lixgen -lixos -lixgls -lnsl -lsocket -laio -lm /usr/local/informix/lib/esql/checkapi.o -lixglx You may need a slightly different definition of LIBS in your environment. Typing "esql -libs" at a command prompt should give you the necessary linking information. -- Tony Ingraldi | e-mail: A.M.INGRALDI@LaRC.NASA.GOV NASA Langley Research Center | Mail Stop 267 | Phone : (757) 864-3039 Hampton, VA 23681-2199 | Fax : (757) 864-7892