From daniel.dittmar@sap.com Thu Feb 1 16:24:26 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Thu, 1 Feb 2001 17:24:26 +0100 Subject: [DB-SIG] Any standards beyond DB API? Message-ID: Now that the DB API module for SAP DB nears completition: are there any features which weren't put into the spec because it was deemed too complex, but which several drivers implement anyway, possibly in a similar way? - configurable automatic translation of SQL values to Python values depending on the type (especially for Date, Time and Timestamp) - catalog information - handling of Blobs/Clobs Daniel -- Daniel Dittmar daniel.dittmar@sap.com SAP DB, SAP Labs Berlin http://www.sapdb.org/ From vranicar@fnal.gov Thu Feb 1 00:39:10 2001 From: vranicar@fnal.gov (Matthew Vranicar) Date: Wed, 31 Jan 2001 18:39:10 -0600 Subject: [DB-SIG] question on CLOBs in DCOracle References: <20010125170102.CFD1BF360@mail.python.org> Message-ID: <3A78B02D.A7204801@fnal.gov> Yes, DCOracle has the tools to handle CLOBS. But, we only have been able to make this work with Oracle v8.0.5. It fails with Oracle 8.1.6 and above. Alas, we are using the old DCOracle, not the new Alpha version available from Zope.org since last week. We are slated to test that soon. You can find some interesting information on how we're handling clobs at a link I have on my working web page at Fermilab at http://www.fnal.gov:8503/vranicar/lob-sample.py. This was only a test script when I was learning how I wanted to handle inserting and updating CLOB columns. Our final code used similar logic, but there are no guarantees that this code is 100% bullet proof. As for reading, it is extremely simple. Just do either a fetchmany() or a fetchall() to get the resolved content of your lob, or if you want the Lob object just do a fetchone(). The Lob object is needed to do the updates shown in my example. Also, Perl and the DBDOracle module have a very similar concept. This is from other code we have that handles reading CLOBS in Perl/Oraperl. But, personally, I think Python and DCOracle were far easier than the perl/oraperl approach. # These are actually set by external configuration, but hard-coded here # for the completeness of this example. my $dblong = 8192; # size of blob chunks ($ora_long) my $dbtrunc = 1; # raise $ora_error = 1406 if blob > $dblong my $dbblob = 112; # blob data type code, see OCI doc. my $dbchunks = 500; # max number of blob chunks to retrieve, # this max number does not seem to be working # correctly, as it gets all chunks. # Lob truncated, see where and use blob_read. if ($ora_errno == 1406) { for $b (0..$#{data_types}) { if ($data_types[$b] == $dbblob) { # blob type, use blob_read to fix truncation. my $offset = 0; my @frags; my $k= 0; while ($k < $dbchunks) { my $frag = $csr->blob_read($data_titles[$b],$offset,$dblong); $krok .= "f$k: $frag"; last unless defined $frag; my $len = length $frag; $krok .= " ($len"; last unless $len; push(@frags,$frag); $offset += $len; $krok .= " --> $offset)"; $k++; } $dr->[$b] = join("",@frags); } } } > Subject: [DB-SIG] question on CLOBs in DCOracle > Date: Wed, 24 Jan 2001 21:07:51 -0800 (PST) > From: Allan Streib > To: db-sig@python.org > > (Sent this a minute ago without a subject; apologies > if this is a duplicate.) > > Hi, > > I'm looking at having to do some script development in > the near future which will require dealing with CLOBs > columns (containing XML) in an Oracle database. My > languages choices are Python or Perl. I don't know > either one at this point, but that's not my concern. > > From what I've seen,I think I would prefer Python as > it it seems cleaner, less cryptic and easier to learn > than Perl. However, what I read in the DCOracle.txt > file concerns me a little; I'm hoping for some > clarification. > > I will be calling Oracle stored procedures to get the > XML-containing CLOB columns. I read that > "Input/output arguments do not support long and long > raw, date, and rowid variables" But elsewhere it > appears that they can be handled using a Buffer. Can > anyone clarify this for me, and does it make a > difference if the CLOB is returned as an IN OUT > argument as opposed to a cursor argument which > contains the CLOB column? > > Also do you know if Oraperl has the same or a similar > issue? > > Thanks. > > __________________________________________________ > Do You Yahoo!? > Yahoo! Auctions - Buy the things you want at great prices. > http://auctions.yahoo.com/ From daniel.dittmar@sap.com Thu Feb 1 15:54:35 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Thu, 1 Feb 2001 16:54:35 +0100 Subject: [DB-SIG] Q: API clarification: display_size, internal_size, precision, sca le Message-ID: Could someone explain more clearly what the diffences are between the various sizes as required by Cursor.description. display_size: I guess this is the maximal number of characters a translation to string would require, so a fixed point number with 3 digits before and two digits after the decimal point would have a display_size of 6 (3 + 2 + 1 char for the point) internal_size: probably, a UNICODE (10) would give a display_size of 10 and an internal_size of 20. What is the intended use? Some databases have a limitation on the record size or key size, so internal_size could be used to calculate this. precision: the number of digits? scale: the number of digits after the decimal point? Thanks for any help Daniel -- Daniel Dittmar daniel.dittmar@sap.com SAP DB, SAP Labs Berlin http://www.sapdb.org/ From mal@lemburg.com Thu Feb 1 23:37:15 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 02 Feb 2001 00:37:15 +0100 Subject: [DB-SIG] Any standards beyond DB API? References: Message-ID: <3A79F32B.1B86625B@lemburg.com> "Dittmar, Daniel" wrote: > > Now that the DB API module for SAP DB nears completition: Do you have a URL ? I'd be very interested in SAP connectivity... (or is SAP DB too low-level to communicate with an existing SAP R/3 installation ?). The URL for the Python DB interface I found was: http://www.sap.com/solutions/technology/sapdb/ Unfortunately, it's only for Python 1.5.2. With the current Python development cycle of around 6 months / release, I think you should consider using distutils to keep up to date. A distribution for Unix or at least Linux would also be a great thing to have -- at least as commercial offering. > are there any features which weren't put into the spec because it was deemed > too complex, but which several drivers implement anyway, possibly in a > similar way? > > - configurable automatic translation of SQL values to Python values > depending on the type (especially for Date, Time and Timestamp) > - catalog information > - handling of Blobs/Clobs The DB API was kept simple by design with the goal of allowing many different backends to be developed. As for the above category of questions, I think only mxODBC (see my Python Pages) exposes these. The semantics of mxODBC are closely related to the ODBC standard, so this may be a good reference for your implementation. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From mal@lemburg.com Fri Feb 2 09:34:43 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 02 Feb 2001 10:34:43 +0100 Subject: [DB-SIG] Q: API clarification: display_size, internal_size, precision, scale References: Message-ID: <3A7A7F33.114C16CD@lemburg.com> "Dittmar, Daniel" wrote: > > Could someone explain more clearly what the diffences are between the > various sizes as required by Cursor.description. > > display_size: I guess this is the maximal number of characters a translation > to string would require, so a fixed point number with 3 digits before and > two digits after the decimal point would have a display_size of 6 (3 + 2 + 1 > char for the point) > > internal_size: probably, a UNICODE (10) would give a display_size of 10 and > an internal_size of 20. What is the intended use? Some databases have a > limitation on the record size or key size, so internal_size could be used to > calculate this. > > precision: the number of digits? > > scale: the number of digits after the decimal point? All of these are standard terms in SQL. display_size and internal_size really don't have much of a meaning nowadays (they came from the old days of having to generate reports using line printers). I'd suggest reading the ODBC docs for details on the others. They sometimes have weird meanings depending on the column type. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From peter.stapleton@sstuk.com Fri Feb 2 10:25:02 2001 From: peter.stapleton@sstuk.com (Stapleton, Peter) Date: Fri, 2 Feb 2001 10:25:02 -0000 Subject: [DB-SIG] RE: DB-SIG digest, Vol 1 #351 - 2 msgs Message-ID: <21910F19E899D411870A00508BB0815A8584D4@UKWATEX01> Please remove Azar.Rauf@sstuk.com from this list as he has left the company Many Thanks Peter Stapleton -----Original Message----- From: db-sig-request@python.org [mailto:db-sig-request@python.org] Sent: 01 February 2001 17:04 To: db-sig@python.org Subject: DB-SIG digest, Vol 1 #351 - 2 msgs Send DB-SIG mailing list submissions to db-sig@python.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.python.org/mailman/listinfo/db-sig or, via email, send a message with subject or body 'help' to db-sig-request@python.org You can reach the person managing the list at db-sig-admin@python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of DB-SIG digest..." ________________________________________________________________________ This message has been checked for all known viruses, by Star Internet, delivered through the MessageLabs Virus Control Centre. For further information visit: http://www.star.net.uk/stats.asp ________________________________________________________________________ This message has been checked for all known viruses, by Star Internet, delivered through the MessageLabs Virus Control Centre. For further information visit: http://www.star.net.uk/stats.asp From daniel.dittmar@sap.com Fri Feb 2 13:36:19 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Fri, 2 Feb 2001 14:36:19 +0100 Subject: [DB-SIG] Any standards beyond DB API? Message-ID: > The URL for the Python DB interface I found was: > > http://www.sap.com/solutions/technology/sapdb/ > > Unfortunately, it's only for Python 1.5.2. There are Python 2.0 versions for Linux and Windows at ftp://ftp.sap.com/pub/sapdb/patch/, look for sapdb-python20*. > A distribution for > Unix or at least Linux would also be a great thing to have The Python API is part of every database installation, at least those made available through www.sapdb.org. > I think you should > consider using distutils to keep up to date right, except for - I haven't really found the time to look into distutils - the binary distribution contains only one file (two when the DB API compatibility module is added) - it isn't implemented on top of a published API, so packing all the headers and sources and tools and ... is not trivial Daniel -- Daniel Dittmar daniel.dittmar@sap.com SAP DB, SAP Labs Berlin http://www.sapdb.org/ From mal@lemburg.com Sat Feb 3 12:32:55 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 03 Feb 2001 13:32:55 +0100 Subject: [DB-SIG] Any standards beyond DB API? References: Message-ID: <3A7BFA77.A8CDC45E@lemburg.com> "Dittmar, Daniel" wrote: > > > The URL for the Python DB interface I found was: > > > > http://www.sap.com/solutions/technology/sapdb/ > > > > Unfortunately, it's only for Python 1.5.2. > > There are Python 2.0 versions for Linux and Windows at > ftp://ftp.sap.com/pub/sapdb/patch/, look for sapdb-python20*. Thanks. > > A distribution for > > Unix or at least Linux would also be a great thing to have > > The Python API is part of every database installation, at least those made > available through www.sapdb.org. I noted that -- you also seem to deliver part of the Python 1.5.2 lib along with the server; why is that ? (I mean, why not the whole package?) > > I think you should > > consider using distutils to keep up to date > > right, except for > - I haven't really found the time to look into distutils > - the binary distribution contains only one file (two when the DB API > compatibility module is added) > - it isn't implemented on top of a published API, so packing all the headers > and sources and tools and ... is not trivial Oh, you don't have to include any header files. All you have to do is tell distutils where to look for these. Writing setup.py files is really simple if you don't need any of the more elaborate features of distutils (like compiling external C libraries). As a result you get package creation for free -- as Windows installer, RPM package or distutils installer. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From daniel.dittmar@sap.com Mon Feb 5 10:03:59 2001 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Mon, 5 Feb 2001 11:03:59 +0100 Subject: [DB-SIG] Any standards beyond DB API? Message-ID: > I noted that -- you also seem to deliver part of the Python 1.5.2 > lib along with the server; why is that ? (I mean, why not the whole > package?) In the next release, loading of the system tables will be implemented in Python (or rather by the Replication Manager scripted through Python). Because our packages are big enough right now, we thought to restrict the Python redistribution to those parts that are really necessary for this task. Daniel -- Daniel Dittmar daniel.dittmar@sap.com SAP DB, SAP Labs Berlin http://www.sapdb.org/ From jeremys@piocon.com Mon Feb 5 17:27:25 2001 From: jeremys@piocon.com (Jeremy Simmons) Date: Mon, 05 Feb 2001 11:27:25 -0600 Subject: [DB-SIG] DCOracle V1.3.2 and Python V2.0 Message-ID: <3A7EE27D.43825087@piocon.com> The following method in the DCOracle/dbi.py file, the dbiDate class needs to be fixed for DCOracle v1_3_2 to be compatible with Python V2. There are possibly more such bugs, but this was one found in our tests. The original code did not pass a sequence in as the argument to mktime, but rather passed in 9 arguments. Adding the parantheses around the 9 arguments is all that is required. This is due to the fact that Python 1 ignored this error and treated the 9 arguments as the sequence, while Python 2's stricter syntax checking catches this error. The WRONG version for Python v2 compatibility: def __float__(self): return float(mktime(self.year, self.month, self.day, self.hour, self.minute, self.second, 0,0,0)) The RIGHT version: def __float__(self): return float(mktime((self.year, self.month, self.day, self.hour, self.minute, self.second, 0,0,0))) This message was processed by the mail server on Mon, 5 Feb 2001 11:24:52. From vranicar@fnal.gov Mon Feb 5 17:49:34 2001 From: vranicar@fnal.gov (Matthew Vranicar) Date: Mon, 05 Feb 2001 11:49:34 -0600 Subject: [DB-SIG] DCOracle V1.3.2 and Python V2.0 Message-ID: <3A7EE7AE.8EFEDD50@fnal.gov> The following method in the DCOracle/dbi.py file, the dbiDate class needs to be fixed for DCOracle v1_3_2 to be compatible with Python V2. There are possibly more such bugs, but this was one found in our tests. The original code did not pass a sequence in as the argument to mktime, but rather passed in 9 arguments. Adding the parantheses around the 9 arguments is all that is required. This is due to the fact that Python 1 ignored this error and treated the 9 arguments as the sequence, while Python 2's stricter syntax checking catches this error. The WRONG version for Python v2 compatibility: def __float__(self): return float(mktime(self.year, self.month, self.day, self.hour, self.minute, self.second, 0,0,0)) The RIGHT version: def __float__(self): return float(mktime((self.year, self.month, self.day, self.hour, self.minute, self.second, 0,0,0))) This message was processed by the mail server on Mon, 5 Feb 2001 11:24:52. From brunson@level3.net Tue Feb 6 00:46:48 2001 From: brunson@level3.net (Eric Brunson) Date: Mon, 5 Feb 2001 17:46:48 -0700 Subject: [DB-SIG] Transaction with DCOracle? In-Reply-To: <3A6C7BE0.54933619@lemburg.com>; from mal@lemburg.com on Mon, Jan 22, 2001 at 07:28:48PM +0100 References: <3A6C7BE0.54933619@lemburg.com> Message-ID: <20010205174648.A2477@level3.net> * M.-A. Lemburg (mal@lemburg.com) [010122 11:35]: > Peter Sabaini wrote: > > > > i do something like > > > > ---------------- > > from DCOracle import Connect, error > > try: cursor.somedangerous_sql() > > except error, detail: cursor.rollback() > > ---------------- > > A general warning on this kind of approach: not all SQL > commands can be rolled back, e.g. dropping a table is not > necessarily reversable... I don't think you can execute DDL though these interfaces. At least not with Oracle, only DML. -- Eric Brunson - brunson@level3.net - page-eric@level3.net "When governments fear the people there is liberty. When the people fear the government there is tyranny." - Thomas Jefferson From brunson@level3.net Tue Feb 6 01:08:39 2001 From: brunson@level3.net (Eric Brunson) Date: Mon, 5 Feb 2001 18:08:39 -0700 Subject: [DB-SIG] Transaction with DCOracle? In-Reply-To: <20010205174648.A2477@level3.net>; from brunson@level3.net on Mon, Feb 05, 2001 at 05:46:48PM -0700 References: <3A6C7BE0.54933619@lemburg.com> <20010205174648.A2477@level3.net> Message-ID: <20010205180839.A3909@level3.net> * Eric Brunson (brunson@level3.net) [010205 17:52]: > * M.-A. Lemburg (mal@lemburg.com) [010122 11:35]: > > Peter Sabaini wrote: > > > > > > i do something like > > > > > > ---------------- > > > from DCOracle import Connect, error > > > try: cursor.somedangerous_sql() > > > except error, detail: cursor.rollback() > > > ---------------- > > > > A general warning on this kind of approach: not all SQL > > commands can be rolled back, e.g. dropping a table is not > > necessarily reversable... > > I don't think you can execute DDL though these interfaces. At least > not with Oracle, only DML. > Well, the DCOracle2 docs prove me wrong. Never mind *wipes egg from face* e. -- Eric Brunson - brunson@level3.net - page-eric@level3.net "When governments fear the people there is liberty. When the people fear the government there is tyranny." - Thomas Jefferson From brunson@level3.net Tue Feb 6 02:03:49 2001 From: brunson@level3.net (Eric Brunson) Date: Mon, 5 Feb 2001 19:03:49 -0700 Subject: [DB-SIG] ORA-24374 when selecting under DCOracle2 Message-ID: <20010205190349.A5970@level3.net> I just pulled the DCOracle2 package and with a few minor changes got it to compile on my Solaris box. However, I'm getting the following error when trying to do *any* select from python using it. This is a simple example, but all of the test scripts 2-5 fail with the same error. >>> import DCOracle2 >>> dbc = DCOracle2.Connect( 'scott/tiger' ) >>> c = dbc.cursor() >>> c.execute( 'select * from dual' ) Traceback (innermost last): File "", line 1, in ? File "DCOracle2/DCOracle2.py", line 305, in execute self._cursor.execute(params) OracleError: (24374, 'ORA-24374: define not done before fetch or execute and fetch') Oracle has this to say: orb(~/src/DCO2/test)$ oerr ORA 24374 24374, 00000, "define not done before fetch or execute and fetch" // *Cause: The application did not define output variables for data being // fetched before issuing a fetch call or invoking a fetch by // specifying a non-zero row count in an execute call. // *Action: Issue OCI define calls for the columns to be fetched. Here's the offending code: def execute(self, operation, *params): if self._operation != operation: self._cursor.prepare(operation) self._operation = operation i = 0 for p in params: i = i + 1 if type(p) == types.TupleType: self._cursor.bindbypos(i, p[0], p[1]) else: self._cursor.bindbypos(i, p) self._cursor.execute(params) <<<<<<<<<<<<<<<<<<<<<<<< self.description = self.describe() But I'm not sure where the bind should have been done. I don't think it can be done up front, since the static SQL is passed into this very function. Anyway, I'm running Oracle 8.0.5 on Solaris 2.6.1, so does anyone know of problems with either of those? Do I need a newer Oracle? Thanks, e. -- Eric Brunson - brunson@level3.net - page-eric@level3.net "When governments fear the people there is liberty. When the people fear the government there is tyranny." - Thomas Jefferson From Evert@paltrack.co.za Tue Feb 6 07:22:36 2001 From: Evert@paltrack.co.za (Evert@paltrack.co.za) Date: Tue, 6 Feb 2001 09:22:36 +0200 Subject: [DB-SIG] Newbie - Informix DB and Python Message-ID: Hi all.. First of all... i am VERY new in Python...so please bear with me....Thanx We want to use Python 2.1 to access Informix DB with the informixdb toolkit. Both are running on Unix SCO so there is no ODBC issues. I just want to know where to start! Are there examples somewhere bacause i find that the easiest way to learn the new stuff. Thanx a lot. Evert ps. U can email me directly if this is all old hat to u guys! From corour01@motorola.com Thu Feb 8 10:52:45 2001 From: corour01@motorola.com (O'Rourke Clodagh-corour01) Date: Thu, 8 Feb 2001 10:52:45 -0000 Subject: [DB-SIG] Python-Informix Message-ID: <13EE655665F4D311AB4D0008C789498A01EE2C35@zei02exm02.cork.cig.mot.com> Hi all, Could anyone offer advise on what is the best way to retrieve info from Informix using python? I've looked at informixdb but what are the parameters for the connection string? Thanks a lot, Clodagh O' Rourke From fabella@testandgo.com Fri Feb 9 08:28:05 2001 From: fabella@testandgo.com (FABELLA MAGIC) Date: Fri, 9 Feb 2001 09:28:05 +0100 Subject: [DB-SIG] (no subject) Message-ID: From andy@dustman.net Fri Feb 9 17:36:16 2001 From: andy@dustman.net (Andy Dustman) Date: Fri, 9 Feb 2001 12:36:16 -0500 (EST) Subject: [DB-SIG] MySQLdb module 0.3.3 Message-ID: Python Interface to MySQL Stability: Perfect in every way Released: 2001-02-09 00:00 UTC Notes Minor bug-fix release. Some of the SSCursor methods were broken by 0.3.2. If you don't use SSCursor, then you don't need to upgrade. Generally, I don't recommend using SSCursor, but there are some situations where it is useful, primarily with very large result sets. The MySQL people generally recommend using LIMIT start,end clauses in these cases. If you only use MySQLdb with Zope and ZMySQLDA, you don't need this; you can stay with 0.3.2. This is very likely the last release before 1.0.0. If you know of any outstanding issues, please send them to the mailing list. http://dustman.net/andy/python/MySQLdb/0.3.3 -- Andy Dustman PGP: 0xC72F3F1D @ .net http://dustman.net/andy "Normally with carbonara you use eggs, but I used lobster brains instead." -- Masahiko Kobe (Iron Chef Italian): 30-year-old Giant Lobster Battle From kent@springfed.com Sun Feb 11 14:12:04 2001 From: kent@springfed.com (Kent Tenney) Date: Sun, 11 Feb 2001 08:12:04 -0600 Subject: [DB-SIG] Acessing DBISAM files via mxODBC Message-ID: <200102111512.JAA06117@zealot.baysat.net> Howdy, I have data in DBISAM files which I'd like to access via Python. I have installed an ODBC driver for DBISAM; http://www.elevatesoft.com/download/odbc.zip, found at http://www.elevatesoft.com/usercode.htm and mxODBC; http://www.lemburg.com/files/python/mxODBC.html this is my program; import ODBC.Windows as odbc con =3D odbc.Connect('photos', user=3D'', password=3D'') cur =3D con.cursor() --it seems OK at this point; >>> cur I am unable to do anything with the cursor, I keep getting the parameter mismatch message. >>> cur.execute('select * from datafile') Traceback (innermost last): File "", line 1, in ? InterfaceError: mismatch in number of parameters; expected 63,= found none I don't understand this error message. Is the driver just incompatable with the mxODBC module? Any suggestions? Thanks, Kent From mal@lemburg.com Sun Feb 11 14:48:41 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 11 Feb 2001 15:48:41 +0100 Subject: [DB-SIG] Acessing DBISAM files via mxODBC References: <200102111512.JAA06117@zealot.baysat.net> Message-ID: <3A86A649.E3FDD861@lemburg.com> Kent Tenney wrote: > > Howdy, > > I have data in DBISAM files which I'd like to access via Python. > > I have installed an ODBC driver for DBISAM; > http://www.elevatesoft.com/download/odbc.zip, > found at http://www.elevatesoft.com/usercode.htm > > and mxODBC; http://www.lemburg.com/files/python/mxODBC.html > > this is my program; > import ODBC.Windows as odbc > > con = odbc.Connect('photos', user='', password='') > cur = con.cursor() > > --it seems OK at this point; > >>> cur > > > I am unable to do anything with the cursor, I keep getting the > parameter mismatch message. > > >>> cur.execute('select * from datafile') > Traceback (innermost last): > File "", line 1, in ? > InterfaceError: mismatch in number of parameters; expected 63, found none > > I don't understand this error message. > > Is the driver just incompatable with the mxODBC module? > > Any suggestions? Could you send the mxODBC.log which is generated by mxODBC when Python is run in debug mode (python -d) ? This should give some insights into why the interface expects 63 parameters :-) -- this looks like a bug in the ODBC driver... -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From kent@springfed.com Sun Feb 11 20:00:02 2001 From: kent@springfed.com (Kent Tenney) Date: Sun, 11 Feb 2001 14:00:02 -0600 Subject: [DB-SIG] Acessing DBISAM files via mxODBC Message-ID: <200102112100.PAA17530@zealot.baysat.net> Marc-Andre, Thanks for the prompt reply. I ran python -d test_db.py this is the contents of test_db.py; import ODBC.Windows as odbc con =3D odbc.Connect('photos', user=3D'', password=3D'') cur =3D con.cursor() cur.execute('select * from SPM_Link') I see from the log file that the program knows about the data in the file. Is there another way to execute an SQL= statement other than as a cursor method? Thanks, Kent This the resulting mxODBC.log --- New Log Session --- Sun Feb 11 12:09:15 2001 Importing the DateTime C API... module found API object found API object initialized. sizeof(mxODBCursor_Variable)=3D76 mxODBC_New: server=3D'photos', uid=3D'', passwd=3D'', clearAC=3D1 mxODBC_New: created new connection at 0x7ba170 mxODBCursor_New: created new cursor '' at 0x7ba010 mxODBCursor_Execute: preparing statement 'select * from= SPM_Link' mxODBCursor_Execute: number of params in statement: 0 mxODBCursor_Execute: executing command without parameters mxODBCursor_FreeVars: called for cursor at 0x7ba010 mxODBCursor_PrepareOutput: colcount=3D2 rowcount=3D11809 mxODBCursor_PrepareOutput: column 0: name=3D'FileID' type=3D4= precision=3D4 scale=3D0 nullable=3D1 mxODBCursor_PrepareOutput: column 1: name=3D'KeywordID' type=3D4= precision=3D4 scale=3D0 nullable=3D1 mxODBCursor_Free: called for cursor at 0x7ba010 mxODBCursor_FreeVars: called for cursor at 0x7ba010 mxODBCursor_FreeVars: freeing output variable array mxODBCursor_FreeParameters: called for cursor at 0x7ba010 mxODBCursor_Close: called for cursor at 0x7ba010 mxODBCursor_Close: error cancelling; rc=3D-1mxODBCursor_Close: = stmt freed mxODBC_Free: called for connection at 0x7ba170 mxODBC_Close: called for connection at 0x7ba170, closed=3D0 mxODBC_Close: disconnect mxODBC_Close: free connection On Sun, 11 Feb 2001 15:48:41 +0100, M.-A. Lemburg wrote: Kent Tenney wrote: > > Howdy, > > I have data in DBISAM files which I'd like to access via= Python. > > I have installed an ODBC driver for DBISAM; > http://www.elevatesoft.com/download/odbc.zip, > found at http://www.elevatesoft.com/usercode.htm > > and mxODBC; http://www.lemburg.com/files/python/mxODBC.html > > this is my program; > import ODBC.Windows as odbc > > con =3D odbc.Connect('photos', user=3D'', password=3D'') > cur =3D con.cursor() > > --it seems OK at this point; > >>> cur > > > I am unable to do anything with the cursor, I keep getting the > parameter mismatch message. > > >>> cur.execute('select * from datafile') > Traceback (innermost last): > File "", line 1, in ? > InterfaceError: mismatch in number of parameters; expected 63,= found none > > I don't understand this error message. > > Is the driver just incompatable with the mxODBC module? > > Any suggestions? Could you send the mxODBC.log which is generated by mxODBC when Python is run in debug mode (python -d) ? This should give some insights into why the interface expects 63 parameters :-) -- this looks like a bug in the ODBC driver... -- Marc-Andre Lemburg _________________________________________________________________= _____ Company: = http://www.egenix.com/ Consulting: = http://www.lemburg.com/ Python Pages: = http://www.lemburg.com/python/ _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig From mal@lemburg.com Sun Feb 11 21:20:12 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun, 11 Feb 2001 22:20:12 +0100 Subject: [DB-SIG] Acessing DBISAM files via mxODBC References: <200102112100.PAA17530@zealot.baysat.net> Message-ID: <3A87020C.EFB02766@lemburg.com> Kent Tenney wrote: > > Marc-Andre, > > Thanks for the prompt reply. > I ran python -d test_db.py > this is the contents of test_db.py; > > import ODBC.Windows as odbc > con = odbc.Connect('photos', user='', password='') > cur = con.cursor() > cur.execute('select * from SPM_Link') > > I see from the log file that the program knows about the > data in the file. Is there another way to execute an SQL statement > other than as a cursor method? No, you always have to use a cursor (ODBC requires this). Are you sure that the above script does not run ? The log indicates that the .execute() ran just fine... (otherwise the log file wouldn't contain the prepare output lines) ?! > Thanks, > Kent > > This the resulting mxODBC.log > > --- New Log Session --- Sun Feb 11 12:09:15 2001 > > Importing the DateTime C API... > module found > API object found > API object initialized. > sizeof(mxODBCursor_Variable)=76 > mxODBC_New: server='photos', uid='', passwd='', clearAC=1 > mxODBC_New: created new connection at 0x7ba170 > mxODBCursor_New: created new cursor '' at 0x7ba010 > mxODBCursor_Execute: preparing statement 'select * from SPM_Link' > mxODBCursor_Execute: number of params in statement: 0 > mxODBCursor_Execute: executing command without parameters > mxODBCursor_FreeVars: called for cursor at 0x7ba010 > mxODBCursor_PrepareOutput: colcount=2 rowcount=11809 > mxODBCursor_PrepareOutput: column 0: name='FileID' type=4 precision=4 scale=0 nullable=1 > mxODBCursor_PrepareOutput: column 1: name='KeywordID' type=4 precision=4 scale=0 nullable=1 > mxODBCursor_Free: called for cursor at 0x7ba010 > mxODBCursor_FreeVars: called for cursor at 0x7ba010 > mxODBCursor_FreeVars: freeing output variable array > mxODBCursor_FreeParameters: called for cursor at 0x7ba010 > mxODBCursor_Close: called for cursor at 0x7ba010 > mxODBCursor_Close: error cancelling; rc=-1mxODBCursor_Close: stmt freed > mxODBC_Free: called for connection at 0x7ba170 > mxODBC_Close: called for connection at 0x7ba170, closed=0 > mxODBC_Close: disconnect > mxODBC_Close: free connection -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From kent@springfed.com Mon Feb 12 03:03:19 2001 From: kent@springfed.com (Kent Tenney) Date: Sun, 11 Feb 2001 21:03:19 -0600 Subject: [DB-SIG] Acessing DBISAM files via mxODBC In-Reply-To: <3A87020C.EFB02766@lemburg.com> Message-ID: <200102120404.WAA32229@zealot.baysat.net> Marc-Andre, This is the first time I've run from the command line, I was= getting errors when I ran the cur.execute('SQL...') from the interactive= window of ActiveState Python. It does look like I have a cursor which is hooked to the data= OK. Is it common to get different results from interactive Pythonwin= and sending a file to python.exe? Thanks, Kent On Sun, 11 Feb 2001 22:20:12 +0100, M.-A. Lemburg wrote: Kent Tenney wrote: > > Marc-Andre, > > Thanks for the prompt reply. > I ran python -d test_db.py > this is the contents of test_db.py; > > import ODBC.Windows as odbc > con =3D odbc.Connect('photos', user=3D'', password=3D'') > cur =3D con.cursor() > cur.execute('select * from SPM_Link') > > I see from the log file that the program knows about the > data in the file. Is there another way to execute an SQL= statement > other than as a cursor method? No, you always have to use a cursor (ODBC requires this). Are you sure that the above script does not run ? The log indicates that the .execute() ran just fine... (otherwise the log file wouldn't contain the prepare output lines) ?! > Thanks, > Kent > > This the resulting mxODBC.log > > --- New Log Session --- Sun Feb 11 12:09:15 2001 > > Importing the DateTime C API... > module found > API object found > API object initialized. > sizeof(mxODBCursor_Variable)=3D76 > mxODBC_New: server=3D'photos', uid=3D'', passwd=3D'', clearAC=3D1 > mxODBC_New: created new connection at 0x7ba170 > mxODBCursor_New: created new cursor '' at 0x7ba010 > mxODBCursor_Execute: preparing statement 'select * from= SPM_Link' > mxODBCursor_Execute: number of params in statement: 0 > mxODBCursor_Execute: executing command without parameters > mxODBCursor_FreeVars: called for cursor at 0x7ba010 > mxODBCursor_PrepareOutput: colcount=3D2 rowcount=3D11809 > mxODBCursor_PrepareOutput: column 0: name=3D'FileID' type=3D4= precision=3D4 scale=3D0 nullable=3D1 > mxODBCursor_PrepareOutput: column 1: name=3D'KeywordID' type=3D4= precision=3D4 scale=3D0 nullable=3D1 > mxODBCursor_Free: called for cursor at 0x7ba010 > mxODBCursor_FreeVars: called for cursor at 0x7ba010 > mxODBCursor_FreeVars: freeing output variable array > mxODBCursor_FreeParameters: called for cursor at 0x7ba010 > mxODBCursor_Close: called for cursor at 0x7ba010 > mxODBCursor_Close: error cancelling; rc=3D-1mxODBCursor_Close: = stmt freed > mxODBC_Free: called for connection at 0x7ba170 > mxODBC_Close: called for connection at 0x7ba170, closed=3D0 > mxODBC_Close: disconnect > mxODBC_Close: free connection -- Marc-Andre Lemburg _________________________________________________________________= _____ Company: = http://www.egenix.com/ Consulting: = http://www.lemburg.com/ Python Pages: = http://www.lemburg.com/python/ _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig From mal@lemburg.com Mon Feb 12 09:48:46 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 12 Feb 2001 10:48:46 +0100 Subject: [DB-SIG] Acessing DBISAM files via mxODBC References: <200102120404.WAA32229@zealot.baysat.net> Message-ID: <3A87B17E.3EF4E2E9@lemburg.com> Kent Tenney wrote: > > Marc-Andre, > > This is the first time I've run from the command line, I was getting > errors when I ran the cur.execute('SQL...') from the interactive window > of ActiveState Python. > > It does look like I have a cursor which is hooked to the data OK. That's what I thought... > Is it common to get different results from interactive Pythonwin and > sending a file to python.exe? Not really, but then the ODBC driver you are using is so buggy I wouldn't be too surprised (I downloaded it and tried to run the test.py script on it... failed badly with some really wild results). I'd write to the driver's maintainer about this -- in it current state it is not very useful. BTW, are you bound to keeping the data in those DBISAM files ? There are much better quality ODBC drivers which interface to the MS Jet Engine available from Microsoft (just download and install their MDAC lib). The Jet engine is the database engine driving Access, BTW, and since it's free, I'd suggest taking a look at it. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/ From Claudius.Schnoerr@ddg.de Tue Feb 13 18:26:49 2001 From: Claudius.Schnoerr@ddg.de (=?iso-8859-1?Q?=22Schn=F6rr=2C_Claudius_Dr=2E=22?=) Date: Tue, 13 Feb 2001 19:26:49 +0100 Subject: [DB-SIG] Q: Is there a version of DCOracle for Oracle-8.1.6 and Python-2.0 ? Message-ID: <30E10C5E4EE6D31181EF00508B8B5BBB1176D1@EXCHANGE-SERVER.ddg.de> Hello, are there updated versions of - Setup-8.1.6 and - Makefile.pre.in-2.0 of DCOracle? Is there a reliable support for these files to be patched in time? Using the latest with Oracle-8.1.6 results in compilation errors: gcc -I/oracle/orapddg/product/8.1.6/rdbms/demo -I/oracle/orapddg/product/8.1.6/network/public -I/oracle/orapddg/product/8.1.6/plsql/public -DDCORACLE8 -g -I/home/pddg/ekdmg/local/Pythons/include/python2.0 -I/home/pddg/ekdmg/local/Pythons/include/python2.0 -DHAVE_CONFIG_H -c ./oci_.c In file included from oci_8.c:67, from ./oci_.c:697: /oracle/orapddg/product/8.1.6/rdbms/demo/oci.h:1635: ociextp.h: No such file or directory In file included from oci_8.c:67, from ./oci_.c:697: /oracle/orapddg/product/8.1.6/rdbms/demo/oci.h:1651: ociextp.h: No such file or directory make: *** [oci_.o] Error 1 Thank you for yout help in advance! Please send a copy of your answer directly to me by email because I do not frequently read this group. With best wishes, Claudius ------------------------------------------------------------------------- Dr.-Ing. Claudius Schnoerr DDG Gesellschaft fuer Verkehrsdaten mbH Niederkasseler Lohweg 20 Tel: ++49-(0)211-52777-423 40547 Duesseldorf Fax: ++49-(0)211-52777-109 email: Claudius.Schnoerr@ddg.de ------------------------------------------------------------------------- ---------------------------------------------------------------------- This Mail has been checked for Viruses Attention: Encrypted Mails can NOT be checked ! * * * Diese Mail wurde auf Viren ueberprueft Hinweis: Verschluesselte Mails koennen NICHT geprueft werden ! ---------------------------------------------------------------------- From brunson@level3.net Wed Feb 14 00:35:22 2001 From: brunson@level3.net (Eric Brunson) Date: Tue, 13 Feb 2001 17:35:22 -0700 Subject: [DB-SIG] ORA-24374 when selecting under DCOracle2 In-Reply-To: <20010205190349.A5970@level3.net>; from brunson@level3.net on Mon, Feb 05, 2001 at 07:03:49PM -0700 References: <20010205190349.A5970@level3.net> Message-ID: <20010213173522.A9619@level3.net> Seems to work in Alpha 2. * Eric Brunson (brunson@level3.net) [010205 19:09]: > > I just pulled the DCOracle2 package and with a few minor changes got > it to compile on my Solaris box. > > However, I'm getting the following error when trying to do *any* > select from python using it. This is a simple example, but all of the > test scripts 2-5 fail with the same error. > > >>> import DCOracle2 > >>> dbc = DCOracle2.Connect( 'scott/tiger' ) > >>> c = dbc.cursor() > >>> c.execute( 'select * from dual' ) > Traceback (innermost last): > File "", line 1, in ? > File "DCOracle2/DCOracle2.py", line 305, in execute > self._cursor.execute(params) > OracleError: (24374, 'ORA-24374: define not done before fetch or execute and fetch') > > Oracle has this to say: > > orb(~/src/DCO2/test)$ oerr ORA 24374 > 24374, 00000, "define not done before fetch or execute and fetch" > // *Cause: The application did not define output variables for data being > // fetched before issuing a fetch call or invoking a fetch by > // specifying a non-zero row count in an execute call. > // *Action: Issue OCI define calls for the columns to be fetched. > > > Here's the offending code: > > def execute(self, operation, *params): > if self._operation != operation: > self._cursor.prepare(operation) > self._operation = operation > i = 0 > for p in params: > i = i + 1 > if type(p) == types.TupleType: > self._cursor.bindbypos(i, p[0], p[1]) > else: > self._cursor.bindbypos(i, p) > self._cursor.execute(params) <<<<<<<<<<<<<<<<<<<<<<<< > self.description = self.describe() > > But I'm not sure where the bind should have been done. I don't think > it can be done up front, since the static SQL is passed into this very > function. > > Anyway, I'm running Oracle 8.0.5 on Solaris 2.6.1, so does anyone know > of problems with either of those? Do I need a newer Oracle? > > Thanks, > e. > > -- > Eric Brunson - brunson@level3.net - page-eric@level3.net > > "When governments fear the people there is liberty. When the people > fear the government there is tyranny." - Thomas Jefferson > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig -- Eric Brunson - brunson@level3.net - page-eric@level3.net "When governments fear the people there is liberty. When the people fear the government there is tyranny." - Thomas Jefferson From cmkleffner@web.de Thu Feb 15 11:17:51 2001 From: cmkleffner@web.de (Carl-Michael Kleffner) Date: Thu, 15 Feb 2001 12:17:51 +0100 Subject: [DB-SIG] dbiDate and informixdb1.3 problem Message-ID: <200102151117.f1FBHpX02349@mailgate3.cinetic.de> Hi ! Is there a possibility to read 'DATE' datafields with dates beyond Jan 19 2038 (max. UNIX time). I have to read full rows of data from a relation (select *... Too many errors encountered; the rest of the message is ignored: with different data types - some of them have DATE type. Dates beyond max UNIX date seems to be silently converted to dbiDate with the value dbi.dbiDate(-1). Any solution with informixdb =3D3F Sincerly Carl cmkleffner@web.de =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F Die Fachpresse ist sich einig: WEB.DE 18mal Testsieger! Kostenlos E-Mail,=20 Fax, SMS, Verschl=FCsselung, POP3, WAP....testen Sie uns! http://freemail.we= b.de From anand123abc@hotmail.com Thu Feb 15 14:15:06 2001 From: anand123abc@hotmail.com (Anand Patel) Date: Thu, 15 Feb 2001 14:15:06 -0000 Subject: [DB-SIG] ODBC Message-ID: Hi I am a final year student trying to complete a project. But I've got one problem and was hoping someone here can help. Basically, I am using Python on a Windows platform and want to connect to Oracle, but I'm not technically competent. From what I understand so far, I have to download Mark Hammonds win32 extensions. But is that it. I thought I would have to do something in Oracle so it knows that Python is going to interact with it. Any help would be great, I would prefer it if people could e-mail me directly. Thanks Anand _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From uche.ogbuji@fourthought.com Mon Feb 19 23:40:46 2001 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Mon, 19 Feb 2001 16:40:46 -0700 Subject: [DB-SIG] ANN: 4Suite and 4Suite Server 0.10.2 Message-ID: <200102192340.QAA21355@localhost.localdomain> Fourthought, Inc. (http://Fourthought.com) announces the release of 4Suite 0.10.2 and 4Suite Server 0.10.2 ---------------------------- Open source XML processing tools and an XML data server http://4Suite.org http://Fourthought.com/4SuiteServer 4Suite News ----------- * ODS: optimized back end * ODS: Better collection support * ODS: DBM and Oracle driver fixes * XSLT: format-number overhaul * XPath: C boolean extension implemented for performance * XPath: Added extension functs search-re, base-uri * RDF: serialization fixes * RDF: shelve (DBM) driver * Localization support * Friendlier error messages * URI handling fixes * Many misc bug-fixes 4Suite Server News ------------------ * Many usability improvements * omniNotify: Removed our implementation of Event Channel and replaced with omniNotify * TxFactory: Rewrote to avoid common race conditions * Strobe: (formerly Reaper) Added a test harness * UserServer: Moved many user specific things out of the common IDL * UserServer: Added a test harness * RdfServer: Now uses system exceptions for common exception cases. * RdfServer: Added a test harness * XmlServer: Allow Raw files * XmlServer: Now uses the standard system exceptions * XmlServer: Added a proper test harness * XmlServer: Added XSLT-based API to 4SS * MetaUserServer: Completed the implementation * MetaUserServer: Added a proper test harness * MetaXmlServer: Completed the implementation * MetaXmlServer: Added a proper test harness * HTTPListener: Added a test harness * HTTPListener: XSLT support * HTTPListener: Custom handler support * webDAV: Incorporated pydav into 4SS * webDAV: Finished initial implementation * All: Renamed interfaces (where approriate) to follow Create/Fetch/Update/Delete naming convention. * All: Added command-line tools * All: Added console * All: Added populate script to bootstrap useful resources * All: More comprehensive documentation * All: Many, many fixes and optimizations 4Suite is a collection of Python tools for XML processing and object database management. It provides support for XML parsing, several transient and persistent DOM implementations, XPath expressions, XPointer, XSLT transforms, XLink, RDF and ODMG object databases. 4Suite Server is a platform for XML processing. It features an XML data repository, a rules-based engine, and XSLT transforms, XPath and RDF-based indexing and query, XLink resolution and many other XML services. It also supports related services such as distributed transactions and access control lists. Along with basic console and command-line management, it supports remote, cross-platform and cross-language access through CORBA, WebDAV, HTTP and other request protocols to be added shortly. 4Suite Server is not meant to be a full-blown application server. It provides highly-specialized services for XML processing that can be used with other application servers. All the software is open-source and free to download. Priority support and customization is available from Fourthought, Inc. For more information on this, see the http://FourThought.com, or contact Fourthought at info@fourthought.com or +1 303 583 9900 More info and Obtaining 4Suite and 4Suite Server ------------------------------------------------ Please see http://4Suite.org http://Fourthought.com/4SuiteServer >From where you can download source, Windows and Linux binaries. 4Suite is distributed under a license similar to that of the Apache Web Server. From djc@object-craft.com.au Thu Feb 22 10:50:36 2001 From: djc@object-craft.com.au (Dave Cole) Date: 22 Feb 2001 21:50:36 +1100 Subject: [DB-SIG] Sybase module 0.12 (Aki Yamashita release) released Message-ID: --=-=-= What is it: The Sybase module provides a Python interface to the Sybase relational database system. The Sybase package supports almost all of the Python Database API, version 2.0 with extensions. The module works with Python versions 1.5.2 and later and Sybase versions 11.0.3 and later. It is based on the Sybase Client Library (ct_* API), and the Bulk-Library Client (blk_* API) interfaces. Changes: - A bug has been fixed in the bulkcopy object which caused FLOAT columns to be corrupted on transfer to the server. Where can you get it: http://www.object-craft.com.au/projects/sybase/ - Dave -- http://www.object-craft.com.au --=-=-= -- http://www.object-craft.com.au --=-=-=-- From mal@lemburg.com Thu Feb 22 22:05:04 2001 From: mal@lemburg.com (M.-A. Lemburg) Date: Thu, 22 Feb 2001 23:05:04 +0100 Subject: [DB-SIG] ANN: eGenix.com mx Extensions -- Version 2.0.0 (mxODBC, mxDateTime, ...) Message-ID: <3A958D10.13416880@lemburg.com> ________________________________________________________________________ ANNOUNCING: eGenix.com mx Extension Series for Python Version 2.0.0 Full Source Python extensions providing important and useful services for Python programmers. ________________________________________________________________________ WHAT IS IT ? The eGenix.com mx Extensions for Python are a collection of professional quality software tools which enhance Python's usability in many important areas such as ODBC database connectivity, fast text processing, date/time processing and web site programming. Python is an open-oriented Open Source programming language which runs on all modern platforms. By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. The tools have a proven record of being portable across many Unix and Windows platforms, e.g. you can write applications which use an ODBC database on Windows which then run on Unix platforms without change due to the consistent platforms independent interfaces. All available packages have proven their stability and usefulness in many mission critical applications and various commercial settings all around the world. The two most well-known subpackages from the eGenix.com mx Extension Series are mxDateTime and mxODBC providing date/time services and professional ODBC database connectivity on practically all supported Python platforms. These two packages enable database software which is portable not only across platforms, but also across database backends. ________________________________________________________________________ WHAT'S NEW ? mxODBC, mxDateTime and all other mx packages are now maintained by my new company eGenix.com Software GmbH, Langenfeld in Germany (http://www.egenix.com/). This move will provide a better base for future development and also assures the availability of commercial support, which is important for companies building applications based on the eGenix.com mx Extensions. The new versions of the eGenix.com mx Extensions use the Python 2.0 distutils packaging technology to simplify installation and use of the many different subpackages. This is expected to greatly enhance the installation and usage experience of the software. In additions to many subpackage enhancements, this new release repackages all mx Extensions under a new top-level package named 'mx'. This will allow you to use the subpackages side-by-side with other Python tools using similar names. The software is now delivered in two download archives: the eGenix.com mx BASE package which holds all the Open Source tools from the series and provides the basis for the other add-ons and the eGenix.com mx COMMERCIAL package which currently only contains the mxODBC package. The two packages are covered by the eGenix.com Public License and the eGenix.com Commercial License respectively. Details about the licenses can be found at: http://www.lemburg.com/files/python/mxLicense.html ________________________________________________________________________ SPECIAL OFFER theKompany.com has licensed the COMMERCIAL package (which includes mxODBC) for inclusion in their brand new Qt-based Python IDE BackAdder. It allows developing portable GUI-based database applications which run on Windows and Linux platforms without any change to the source code. BlackAdder includes a 1 CPU license for this package at no extra cost, so you may want to check out their great new product. See http://www.lemburg.com/files/python/eGenix-mx-Extensions.html#BlackAdder for details. ________________________________________________________________________ EGENIX.COM MX BASE PACKAGE OVERVIEW: mxDateTime - Generic Date/Time Types mxDateTime is an extension package that provides three new object types, DateTime, DateTimeDelta and RelativeDateTime, which let you store and handle date/time values in a much more natural way than by using ticks (seconds since 1.1.70 0:00 UTC; the encoding used by the time module). You can add, subtract and even multiply instances, pickle and copy them and convert the results to strings, COM dates, ticks and some other more esoteric values. In addition, there are several convenient constructors and formatters at hand to greatly simplify dealing with dates and times in real-world applications. In addition to providing an easy-to-use Python interface the package also exports a comfortable C API interface for other extensions to build upon. This is especially interesting for database applications which often have to deal with date/time values (the mxODBC package is one example of an extension using this interface). mxTextTools - Fast Text Processing Tools mxTextTools is an extension package for Python that provides several useful functions and types that implement high-performance text manipulation and searching algorithms in addition to a very flexible and extendable state machine, the Tagging Engine, that allows scanning and processing text based on low-level byte-code "programs" written using Python tuples. It gives you access to the speed of C without the need to do any compile and link steps every time you change the parsing description. Applications include parsing structured text, finding and extracting text (either exact or using translation tables) and recombining strings to form new text. mxStack - Fast and Memory-Efficient Stack Type mxStack is an extension package that provides a new object type called Stack. It works much like what you would expect from such a type, having .push() and .pop() methods and focusses on obtaining maximum speed at low memory costs. mxTools - Collection of Additional Builtins mxTools is an extension package that includes a collection of handy functions and objects giving additional functionality in form of new builtins to the Python programmer. The package auto-installs the new functions and objects as builtins upon first import. This means that they become instantely available to all other modules without any further action on your part. Add the line import NewBuiltins to your site.py script and they will be available to all users at your site as if they were installed in the Python interpreter itself. mxProxy - Generic Proxy Wrapper Type mxProxy is an extension package that provides a new type that is suitable to implement Bastion like features without the need to use restricted execution environments. The type's main features are secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods and a cleanup protocol that helps in breaking circular references prior to object deletion. The latest version adds a very interesting new feature: weak references which help you work with circular references in a way that doesn't cause memory leakage in a Python system. mxBeeBase - On-disk B+Tree Based Database Kit mxBeeBase is a high performance construction kit for disk based indexed databases. It offers components which you can plug together to easily build your own custom mid-sized databases (the current size limit is sizeof(long) which gives you an address range of around 2GB on 32-bit platforms). The two basic building blocks in mxBeeBase are storage and index. Storage is implemented as variable record length data storage with integrated data protection features, automatic data recovery and locking for multi process access. Indexes use a high performance optimized B+Tree implementation built on top of Thomas Niemann's Cookbook B+Tree implementation (http://epaperpress.com/). Note: mxBeeBase is new in this release and still in beta. ________________________________________________________________________ EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW: mxODBC - Generic ODBC 2.0 interface mxODBC is an extension package that provides a Python Database API compliant interface to ODBC 2.0 capable database drivers and managers. In addition to the capabilities provided through the standard DB API it also gives access to a rich set of catalog methods which allow you to scan the database for tables, procedures, etc. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other in/output formats are available too). The latest version of the interface allows you to interface to more than one database from one process. It includes a varity of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid and many more. A precompiled version of the extension for use with the Windows ODBC manager is also included. ________________________________________________________________________ WHERE CAN I GET IT ? The download archives and instructions for installing the packages can be found at: http://www.lemburg.com/files/python/ ________________________________________________________________________ WHAT DOES IT COST ? The BASE packages come with a Python 2.0 style license, which means that you can use them in both commercial and non-commercial settings without fee or charge. All packages come with full source code. mxODBC comes with a new licenses which allows non-commercial use at no charge, but costs a moderate fee for commercial use. Please see http://www.lemburg.com/files/python/eGenix-mx-Extensions.html#mxCOMMERCIAL for details. ________________________________________________________________________ WHERE CAN I GET SUPPORT ? Commercial quality support for these packages is available from eGenix.com Software GmbH. Please see http://www.lemburg.com/files/python/eGenix-mx-Extensions.html#Support for details about the eGenix support offerings. ________________________________________________________________________ REFERENCE:

eGenix.com mx Extension Series - eGenix.com mx Extension Series with distutils support and precompiled binaries for Windows and Linux. (22-Feb-2001) ________________________________________________________________________ ...thanks for reading this far ;-) In the spirit of Python software announcements, I am leaving off for the Python Conference in Long Beach, California tomorrow. If you have any problems with these packages or the downloads, please email me at mal@egenix.com. I will read your mail once I get back from the conference and will do my best make the eGenix.com mx Extensions a success for you. See you at the conference, -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/ From matt@clondiag.com Mon Feb 26 10:33:26 2001 From: matt@clondiag.com (Matthias Kirst) Date: Mon, 26 Feb 2001 11:33:26 +0100 Subject: [DB-SIG] Opinion License mxODBC-Module Message-ID: <3A9A30F6.481BF868@clondiag.com> I have the following understandings of Python and databases: - Python is free even for commercial use - Database connectivity is one of the key features - ODBC is one of the standards for connecting to a database under Windows-OS But : - mxODBC , the quasi-standard ODBC - module has a commercial developer license which costs almost 1500 US$ What will happen to Python when all of the other modules like pyXML will switch to this licensing model ??!! Using Python for commercial projects will cost thousands of dollars from the start up. That taking into account Microsoft with its Visual Studio will definitely make the race. Matthias. From dieter@sz-sb.de Mon Feb 26 11:05:16 2001 From: dieter@sz-sb.de (Dr. Dieter Maurer) Date: Mon, 26 Feb 2001 12:05:16 +0100 (CET) Subject: [DB-SIG] Opinion License mxODBC-Module In-Reply-To: <3A9A30F6.481BF868@clondiag.com> References: <3A9A30F6.481BF868@clondiag.com> Message-ID: <15002.13785.930653.379178@dieter.sz-sb.de> Matthias Kirst writes: > - mxODBC , the quasi-standard ODBC - module has a commercial developer > license which costs almost 1500 US$ > > > What will happen to Python when all of the other modules like pyXML will > switch to this licensing model ??!! I fear, that's the long term fate of open source software when they grow mature and must provide a living for their creators/maintainers. Your options are: * stick with an older version that was still free for commercial use * develop your own ODBC interface and (maybe) allow it to be freely used for commercial purposes. * go through COM to access your databases In principle, companies should be prepared to contribute to the refinancing of the software they use. The price for mxODBC may be a bit too high, though. But, it is a new company, it must still find the adequate market prices for its products. Dieter From Andreas Jung" Message-ID: <007101c09ff7$223c75a0$d0063bd0@SUXLAP> There are lots of small companies who live from one or two products. None of them could live from open-source alone. 1500 US$ is a lot of money but remember: it's still free for private use. When you are working on a commercial project then your budget should be large enough to pay this sum. I have been involved in projects where we used open-source software if possible. But in most cases the costs for hardware are much higher than the costs for software (except costs for own development). E.g. when I must pay 250.000 $ for hardware I should have enough money in budget to pay a "small" license fee to a small company. Open-source will also profit from this. Andreas ----- Original Message ----- From: "Matthias Kirst" To: Sent: Monday, February 26, 2001 5:33 AM Subject: [DB-SIG] Opinion License mxODBC-Module > I have the following understandings of Python and databases: > > - Python is free even for commercial use > - Database connectivity is one of the key features > - ODBC is one of the standards for connecting to a database under > Windows-OS > > But : > > - mxODBC , the quasi-standard ODBC - module has a commercial developer > license which costs almost 1500 US$ > > > What will happen to Python when all of the other modules like pyXML will > switch to this licensing model ??!! > Using Python for commercial projects will cost thousands of dollars from > the start up. > That taking into account Microsoft with its Visual Studio will > definitely make the race. > > Matthias. > > > > _______________________________________________ > DB-SIG maillist - DB-SIG@python.org > http://mail.python.org/mailman/listinfo/db-sig From magnus@thinkware.se Mon Feb 26 14:54:37 2001 From: magnus@thinkware.se (Magnus Lycka) Date: Mon, 26 Feb 2001 15:54:37 +0100 Subject: [DB-SIG] Opinion License mxODBC-Module References: <3A9A30F6.481BF868@clondiag.com> <007101c09ff7$223c75a0$d0063bd0@SUXLAP> Message-ID: <3A9A6E2D.3CF76440@thinkware.se> This is a multi-part message in MIME format. --------------CF00E35DEB20F34150E7C612 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There is a big freedom in developing with free software, also in a commercial setting. Scunk works can be very important and I think that most companies that use Python today started using it without any decisions from management--but on the initiative of those who understand this best: The programmers. Maybe the biggest advantage of free software is just this: It empowers the programmers. As long as they can find some time (their own free time or some time when they are really supposed to do something else) they can assemble a big system from ready made pieces and their own glue code. They can do this without any budget and without any 'patron'. There is a risk here, but where would the world be if no one took risks... As soon as a there is a bill to pay, there will be questions asked, and that might stop many projects in their infancy. Of course, I think it's best if systems are developed with the enthusiastic support of the management, but sometimes it takes a success to convince them, and then we have a chicken and egg problem. Unix was basically developed like this--bottum-up--and I'm sure many other systems have been as well. Most Linux deployments in commercial settings came like this, and if it hadn't been for the ability to download for free on the net, Linux would never have been the pet operating system of major corps like IBM, and Linus would probably still have been in Finland. Naturally, any software developer may use any licence he or she chooses for the programs he or she writes. I hope that Marc-Andre is earning plenty of money on this. He certainly deserves it. I somehow doubt that it will make him very rich though... Perhaps making sure that mxODBC has as many users as possible and making himself and his company known as the best experts and original developers of the mx-series could earn him more. I somehow have a feeling that he understands that many people will use his software as described above--in commercial systems that aren't really sanctioned. (But you can't write that in your licence. :-) In a way that's a bit sad, because it somehow means that you are promoting cheating, and paying as you should, becomes almost some kind of charity. I certainly wish that I could find a way of financing myself and my family that didn't mean that I had to spend all my time programming boring C++ applications for my customers, instead of interesting, free Python code. This is not so easy... That both MySQL and Zope has gone from commercial to free licences are promising. (More so then when companies on the verge of ruin, like Netscape and Corel, reach out to the free software community like a last straw.) I hope that we'll soon see a good and really free ODBC interface for Python, be it mxODBC or something else. In the mean time I view this as a shortcoming for Python development. In a way, this half-free character of mxODBC is a problem. If it wasn't available for free for private use, someone else would have made an alternative by now... :-( By the way, the eGenix web site seems to be a bit ahead of things: The NEWS section is all about things that "happened" next month??? I thought I saw the 2.0 versions released before March 20, 21... Also, a big gif is not helpful when you want to copy text... Why such a strange web site mock-up? /Magnus Andreas Jung wrote: > > There are lots of small companies who live from one or two products. None of > them > could live from open-source alone. 1500 US$ is a lot of money but remember: > it's still free for private use. When you are working on a commercial > project then your > budget should be large enough to pay this sum. I have been involved in > projects > where we used open-source software if possible. But in most cases the costs > for hardware are much higher than the costs for software (except costs for > own > development). E.g. when I must pay 250.000 $ for hardware I should have > enough money > in budget to pay a "small" license fee to a small company. Open-source will > also profit > from this. > > Andreas > ----- Original Message ----- > From: "Matthias Kirst" ... > > - mxODBC , the quasi-standard ODBC - module has a commercial developer > > license which costs almost 1500 US$ --------------CF00E35DEB20F34150E7C612 Content-Type: text/x-vcard; charset=us-ascii; name="magnus.vcf" Content-Description: Card for Magnus Lycka Content-Disposition: attachment; filename="magnus.vcf" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by texas.it-center.se id f1QF1VU12775 begin:vcard=20 n:Lyck=E5;Magnus tel;cell:+46(0)705 82 80 65 tel;fax:+46(0)706 12 80 65 x-mozilla-html:FALSE url:http://thinkware.se/ org:Thinkware AB adr:;;Alvans vag 99, 1tr;Umea;;907 50;Sweden version:2.1 email;internet:magnus@thinkware.se title:SW Developer / Consultant fn:Magnus Lyck=E5 end:vcard --------------CF00E35DEB20F34150E7C612-- From akuchlin@mems-exchange.org Mon Feb 26 15:07:08 2001 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Mon, 26 Feb 2001 10:07:08 -0500 Subject: [DB-SIG] Opinion License mxODBC-Module In-Reply-To: <3A9A30F6.481BF868@clondiag.com>; from matt@clondiag.com on Mon, Feb 26, 2001 at 11:33:26AM +0100 References: <3A9A30F6.481BF868@clondiag.com> Message-ID: <20010226100708.A15208@ute.cnri.reston.va.us> On Mon, Feb 26, 2001 at 11:33:26AM +0100, Matthias Kirst wrote: >- mxODBC , the quasi-standard ODBC - module has a commercial developer >license which costs almost 1500 US$ The actual standard is the DB-API, and mxODBC just an implementation. Marc-Andre is free to pursue whatever licensing he cares to with his module, and I wish him the best of luck with it. (Though I suspect charging for mxODBC will backfire and result in a resurgence of competition as people implement one-off modules for their database system of choice -- we'll see...) >What will happen to Python when all of the other modules like pyXML will >switch to this licensing model ??!! Not likely to happen. PyXML was written by several people (4Suite, Lars Marius Garshol, Martin von Loewis, etc.) and it would be unlikely that we'd all agree to take it commercial. --amk From magnus@thinkware.se Mon Feb 26 17:40:32 2001 From: magnus@thinkware.se (Magnus Lycka) Date: Mon, 26 Feb 2001 18:40:32 +0100 Subject: [DB-SIG] Python and static SQL References: <3A9A30F6.481BF868@clondiag.com> <20010226100708.A15208@ute.cnri.reston.va.us> Message-ID: <3A9A9510.7E7E5D0E@thinkware.se> This is a multi-part message in MIME format. --------------339B6450505560C3C3AC66C6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This ODBC discussion made me think of something completely different... I haven't actually done a lot of measurements, but I've often read that databases like Oracle and DB2 have much, much better performance using static SQL, than they have with dynamic SQL. Is anyone using static SQL "with" Python? What I mean is: Has anyone here built systems where they do their database calls in C or C++ with embedded SQL, basically placing their database IO in a C or C++ module? If the performance claims are true this should be able to boost performance a lot for standard calls. Lately I've mainly been using SQL databases from Object-Oriented programs, and there I think 90% of the accesses are simple CRUD (Create, Retrieve, Update, Delete) operations, and it seems to me that it would be fairly simple to write a little program that would auto-generate the C or C++ code needed to make these CRUD operations. /Magnus --------------339B6450505560C3C3AC66C6 Content-Type: text/x-vcard; charset=us-ascii; name="magnus.vcf" Content-Description: Card for Magnus Lycka Content-Disposition: attachment; filename="magnus.vcf" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by texas.it-center.se id f1QHlSU14368 begin:vcard=20 n:Lyck=E5;Magnus tel;cell:+46(0)705 82 80 65 tel;fax:+46(0)706 12 80 65 x-mozilla-html:FALSE url:http://thinkware.se/ org:Thinkware AB adr:;;Alvans vag 99, 1tr;Umea;;907 50;Sweden version:2.1 email;internet:magnus@thinkware.se title:SW Developer / Consultant fn:Magnus Lyck=E5 end:vcard --------------339B6450505560C3C3AC66C6-- From Anthony@COMPUTRONIX.com Mon Feb 26 18:01:57 2001 From: Anthony@COMPUTRONIX.com (Anthony Tuininga) Date: Mon, 26 Feb 2001 11:01:57 -0700 Subject: [DB-SIG] Python and static SQL Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0A01E.35730F90 Content-Type: text/plain; charset="iso-8859-1" I have written code against the OCI (Oracle Call Interface) a fair amount and also written a Python DB-API 2.0 compliant module for Oracle (more on that later when I have a better description and a Web page) and I think you are being confused by what Oracle is telling you. Any piece of SQL that is executed _OUTSIDE_ the Oracle database (ie by some client or other) is executed by the OCI which requires a SQL string and bind variables. SQL that is executed from within the database itself (ie views and stored procedures) are optimized by Oracle itself. Dynamic SQL within Oracle is slower than views and stored procedures (although the difference has become quite slight in recent versions of Oracle) but only because at that point the Oracle database must execute OCI calls rather than whatever it happens to do internally. So I believe the only performance improvement you are going to notice is that if the strings passed to the database are known at run-time, you do not have to incur the overhead of generating those strings in the first place. Depending on what the database is actually doing this can be significant or not. Anthony -----Original Message----- From: Magnus Lycka [mailto:magnus@thinkware.se] Sent: Monday, February 26, 2001 10:41 AM To: db-sig@python.org Subject: [DB-SIG] Python and static SQL This ODBC discussion made me think of something completely different... I haven't actually done a lot of measurements, but I've often read that databases like Oracle and DB2 have much, much better performance using static SQL, than they have with dynamic SQL. Is anyone using static SQL "with" Python? What I mean is: Has anyone here built systems where they do their database calls in C or C++ with embedded SQL, basically placing their database IO in a C or C++ module? If the performance claims are true this should be able to boost performance a lot for standard calls. Lately I've mainly been using SQL databases from Object-Oriented programs, and there I think 90% of the accesses are simple CRUD (Create, Retrieve, Update, Delete) operations, and it seems to me that it would be fairly simple to write a little program that would auto-generate the C or C++ code needed to make these CRUD operations. /Magnus ------_=_NextPart_001_01C0A01E.35730F90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [DB-SIG] Python and static SQL

I have written code against the OCI (Oracle Call = Interface) a fair amount and also written a Python DB-API 2.0 compliant = module for Oracle (more on that later when I have a better description = and a Web page) and I think you are being confused by what Oracle is = telling you.

Any piece of SQL that is executed _OUTSIDE_ the = Oracle database (ie by some client or other) is executed by the OCI = which requires a SQL string and bind variables. SQL that is executed = from within the database itself (ie views and stored procedures) are = optimized by Oracle itself. Dynamic SQL within Oracle is slower than = views and stored procedures (although the difference has become quite = slight in recent versions of Oracle) but only because at that point the = Oracle database must execute OCI calls rather than whatever it happens = to do internally.

So I believe the only performance improvement you are = going to notice is that if the strings passed to the database are known = at run-time, you do not have to incur the overhead of generating those = strings in the first place. Depending on what the database is actually = doing this can be significant or not.

Anthony

-----Original Message-----
From: Magnus Lycka [mailto:magnus@thinkware.se]
Sent: Monday, February 26, 2001 10:41 AM
To: db-sig@python.org
Subject: [DB-SIG] Python and static SQL


This ODBC discussion made me think of something = completely
different...

I haven't actually done a lot of measurements, but = I've
often read that databases like Oracle and DB2 have = much,
much better performance using static SQL, than they = have
with dynamic SQL.

Is anyone using static SQL "with" = Python?

What I mean is: Has anyone here built systems where = they
do their database calls in C or C++ with embedded = SQL,
basically placing their database IO in a C or C++ = module?

If the performance claims are true this should be = able to
boost performance a lot for standard calls. Lately = I've
mainly been using SQL databases from Object-Oriented = programs,
and there I think 90% of the accesses are simple = CRUD (Create,
Retrieve, Update, Delete) operations, and it seems = to me
that it would be fairly simple to write a little = program that
would auto-generate the C or C++ code needed to make = these
CRUD operations.


/Magnus

------_=_NextPart_001_01C0A01E.35730F90-- From djc@object-craft.com.au Tue Feb 27 09:42:37 2001 From: djc@object-craft.com.au (Dave Cole) Date: 27 Feb 2001 20:42:37 +1100 Subject: [DB-SIG] Python and static SQL In-Reply-To: Magnus Lycka's message of "Mon, 26 Feb 2001 18:40:32 +0100" References: <3A9A30F6.481BF868@clondiag.com> <20010226100708.A15208@ute.cnri.reston.va.us> <3A9A9510.7E7E5D0E@thinkware.se> Message-ID: >>>>> "Magnus" == Magnus Lycka writes: Magnus> This ODBC discussion made me think of something completely Magnus> different... Magnus> I haven't actually done a lot of measurements, but I've often Magnus> read that databases like Oracle and DB2 have much, much better Magnus> performance using static SQL, than they have with dynamic SQL. How do stored procedures stack up against static SQL? I am in the process of re-implementing my sorry excuse for a Sybase module and have been reading that the only penalty that dynamic SQL had over stored procedures is the initial compile stage. Magnus> What I mean is: Has anyone here built systems where they do Magnus> their database calls in C or C++ with embedded SQL, basically Magnus> placing their database IO in a C or C++ module? Magnus> If the performance claims are true this should be able to Magnus> boost performance a lot for standard calls. Lately I've mainly Magnus> been using SQL databases from Object-Oriented programs, and Magnus> there I think 90% of the accesses are simple CRUD (Create, Magnus> Retrieve, Update, Delete) operations, and it seems to me that Magnus> it would be fairly simple to write a little program that would Magnus> auto-generate the C or C++ code needed to make these CRUD Magnus> operations. I agree that it should be pretty simple. How much faster than insert blah values (?,?,?,?,?) is it going to be when the SQL is compiled once, then you just stream values for the placeholders? Are you able to tell us the measurement results? - Dave -- http://www.object-craft.com.au From magnus@thinkware.se Tue Feb 27 14:28:04 2001 From: magnus@thinkware.se (Magnus Lycka) Date: Tue, 27 Feb 2001 15:28:04 +0100 Subject: Mapping objects to tables, was Re: [DB-SIG] Python and static SQL References: <3A9A30F6.481BF868@clondiag.com> <20010226100708.A15208@ute.cnri.reston.va.us> <3A9A9510.7E7E5D0E@thinkware.se> Message-ID: <3A9BB974.42312BA2@thinkware.se> This is a multi-part message in MIME format. --------------23F59D99BB240DE0D746FF14 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ok...this mail tilted rather heavily in focus as I wrote it. Sorry abut that... > How do stored procedures stack up against static SQL? As I understand it, static SQL is very similar to stored procedures in DB2. In both cases, the SQL commands are stored in the database, and QEP are precalculated etc. I think the interface is the same as well. Of course it depends on your your code. With stored procedures, you can have loops and conditionals etc in one database call. With embedded SQL the actual SQL commands are in the database, but the loops etc are in your C++ app, meaning that you will have to communicate with the database, and transfer data, on each turn in the loop. I think other databases might be rather different from DB2 in how they treat dynamic and static SQL. It seems that Oracle is. So...it depends. Imagine that you have a piece of software that has to look at many lines in the database and eventually return just a little data. E.g. if you need to get the standard deviation for a Poisson distributed set of data--I bet all databases fail on all but normal distribution. In this case I can imagine that a stored procedure beats all alternatives. Sure, your table scan will be as heavy, but you won't have to transport more than a float and some meta-data out of the database. Pulling millions of values to the C++/C/Python app might be a heavy task. Especially if your client program is across the network. If it's a simple CRUD operation, I imagine the difference is slim, and it seems from what Anthony says, that at least for Oracle, the difference is slim also compared to Dynamic SQL. Oracle might have a point here, when they suggest using their tools with PL/SQL that allows you to move the same piece of code from a client into the server as a stored procedure. Then you can profile your code as needed... Not that I think it outweighs the disadvantage of being tied in by their proprietary tools... > I am in the process of re-implementing my sorry excuse for a Sybase > module and have been reading that the only penalty that dynamic SQL > had over stored procedures is the initial compile stage. Maybe we could find the time to make some actual tests if we split the burden between us? But is there really an option for a Python database adapter? > How much faster than > > insert blah values (?,?,?,?,?) > > is it going to be when the SQL is compiled once, then you just stream > values for the placeholders? > > Are you able to tell us the measurement results? Not now. I'm only thinking aloud right now. Not really coding this. I doubt that inserts will be different. Maybe joined selects will be more noticable? If I have two linked objects, I'd like to select the objects linked to one object. Basically, in my thinking, there are five operations that make up almost all communication with the database: INSERT INTO CLASS ... SELECT attributes FROM CLASS WHERE OID = ? UPDATE CLASS ... WHERE OID = ? DELETE FROM CLASS WHERE OID = ? SELECT attributes FROM CLASS WHERE FOREIGN_OID = 'other_class.oid' In general (I'm shifting subject a bit now...) I've been thinking of how to map objects to relational databases in a simple and consistent manner. I'm 100% sold to the concept of artificial keys, but I'm wondering how to handle associations between classes. Using a foreign key in a table is obviously only good for one-to-many or one-to-one assiciations. With many-to-many associations you need a separate link table. I was thinking that it might be good to consistently use CLASS tables for objects, and ASSOCIATION tables for links. Thus, something like this: An object model of: |---------| |--------| |Dept | |Emp | |---------|1_______1..*|--------| |Name |workplace |Name | |Location | |EmpDate | | |1__________1|Salary | |---------| manager|--------| Would lead to the following tables with foreign keys: DEPT ---- oid (pk) Name Location Manager (fk = emp.oid) and EMP --- oid (pk) name salary empDate workplace (fk = dept.oid) With association tables it would instead be: oDEPT ---- oid (pk) Name Location and oEMP --- oid (pk) name salary empDate and lDEPT_MANAGER ------------ dept (unique, fk = odept.oid) emp (unique, fk = oemp.oid) and finally lEMP_WORKPLACE ------------- emp (pk, fk = oemp.oid) dept (fk = odept.oid) This solution leads to more tables and more joins, and it's not really needed unless you have many-to-many relationships. It also leads to more SQL code than above. On the other hand, it has advantages: - It works for all types of asscociations. You only have to change the unique indices on the link-tables to change multiplicity - It makes it easier to change the model, for instance to move the association - I think it makes it easier to reuse tables and code. - It maps better gainst the object model--differentiating between objects/classes and links/associations. Obviously, another issue to consider is how to map classes to tables when you take inheritage into account... There might be some relevant comments and links at http://www.thinkware.se:80/cgi-bin/thinki.cgi/DatabaseDesign Comments? --------------23F59D99BB240DE0D746FF14 Content-Type: text/x-vcard; charset=us-ascii; name="magnus.vcf" Content-Description: Card for Magnus Lycka Content-Disposition: attachment; filename="magnus.vcf" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by texas.it-center.se id f1REZ1U19860 begin:vcard=20 n:Lyck=E5;Magnus tel;cell:+46(0)705 82 80 65 tel;fax:+46(0)706 12 80 65 x-mozilla-html:FALSE url:http://thinkware.se/ org:Thinkware AB adr:;;Alvans vag 99, 1tr;Umea;;907 50;Sweden version:2.1 email;internet:magnus@thinkware.se title:SW Developer / Consultant fn:Magnus Lyck=E5 end:vcard --------------23F59D99BB240DE0D746FF14-- From tjg@exceptionalminds.com Wed Feb 28 19:32:37 2001 From: tjg@exceptionalminds.com (Timothy Grant) Date: Wed, 28 Feb 2001 11:32:37 -0800 Subject: [DB-SIG] PoPy v2.0.1 user competency issues Message-ID: <20010228113237.Z29494@trufflehunter.avalongroup.net> Hi all, Two things: First of all, I have a feeling my lack of knowledge about how a database interface is supposed to work is hindering my ability to understand why PoPy is misbehaving. Here's what I am doing: I get a large quantity of data from an external data source. I parse the data, and then build two SQL queries from it: one that does an insert and one that does an update. I then attempt to do an insert in a try/except block. If the insert fails, I know that I have to do an update and I execute the update in the except block. I started using this before I installed v2.0.1. I also turned autocommit on. I get the feeling that while my code was running it was not working correctly at all. I installed PoPy v2.0.1 and something happened to autocommit. So I commented out all the lines having to do with autocommit and proceeded on my merry way. Now, however, I get the following output from my both my test programme and the "real" programme. Could some one improve my understanding of how these things are supposed to work, and what silliness I have implemented? Posted below is the output from my programme, and then below that the test script itself. Thanks for any input you may have. [homer rmls]$ ./test.py Attempting Insert Attempting Update NOTICE: current transaction is aborted, queries ignored until end of transaction block from PoPy import * #Database settings dbname = 'foobar' dbusername = 'tjg' dbhost = 'localhost' TRUE=True=true=1 def main(): db = connect('dbname=%s user=%s host=%s' % (dbname, dbusername, dbhost)) sqlin = "insert into test values (11, 'Jennifer', '503-555-1212');" sqlup = "update test set name = 'Jennifer' where id = 11;" try: print 'Attempting Insert' cr = db.cursor() cr.execute(sqlin) cr.close() except: print 'Attempting Update' cr = db.cursor() cr.execute(sqlup) cr.close() db.commit() I have a feeling my vim newbieness may have messed up the indentation on the above, though I'm not sure. -- Stand Fast, tjg. Timothy Grant tjg@exceptionalminds.com Red Hat Certified Engineer www.exceptionalminds.com Avalon Technology Group, Inc. <>< (503) 246-3630 >>>>>>>>>>>>>Linux, because rebooting is *NOT* normal<<<<<<<<< >>>>This machine was last rebooted: 42 days 23:27 hours ago<<