Blank

From geolane@sunesis.com Wed May 1 00:05:58 2002 From: geolane@sunesis.com (Lane, George) Date: Tue, 30 Apr 2002 16:05:58 -0700 Subject: [DB-SIG] DCOracle + DCOracle2 Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C1F09B.9698DCC2 Content-Type: multipart/related; boundary="----_=_NextPart_002_01C1F09B.9698DCC2"; type="multipart/alternative" ------_=_NextPart_002_01C1F09B.9698DCC2 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C1F09B.9698DCC2" ------_=_NextPart_003_01C1F09B.9698DCC2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have DCOracle installed on a Solaris machine running Oracle 8.1.6. = Has anyone tried installing DCOracle2 in addition to DCOracle? Any = problems or issues with coexistence? =20 >From an application standpoint, the biggest changes seem to be returning = list of lists using fetchxxx(rather than a list of tuples), and the = executemany statement discussed in the docs (which we hadn't been = using). =20 =20 The longer process is redoing the applications which currently rely on = DCOracle... =20 -+-+-+-+-+-+-+-+-+-+-+-+-+-=20 =20 ------_=_NextPart_003_01C1F09B.9698DCC2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Blank

We have DCOracle installed on a = Solaris=20 machine running Oracle 8.1.6. Has anyone tried installing = DCOracle2 in=20 addition to DCOracle? Any problems or issues with=20 coexistence?

From an application standpoint, = the biggest=20 changes seem to be returning list of lists using fetchxxx(rather than a = list of=20 tuples), and the executemany statement discussed in the docs (which we = hadn't=20 been using).

The longer process is redoing the=20 applications which currently rely on DCOracle...

-+-+-+-+-+-+-+-+-+-+-+-+-+- =

------_=_NextPart_003_01C1F09B.9698DCC2-- ------_=_NextPart_002_01C1F09B.9698DCC2 Content-Type: image/gif; name="Blank Bkgrd.gif" Content-Transfer-Encoding: base64 Content-ID: <774565922@30042002-161c> Content-Description: Blank Bkgrd.gif Content-Location: Blank%20Bkgrd.gif R0lGODlhLQAtAID/AP////f39ywAAAAALQAtAEACcAxup8vtvxKQsFon6d02898pGkgiYoCm6sq2 7iqWcmzOsmeXeA7uPJd5CYdD2g9oPF58ygqz+XhCG9JpJGmlYrPXGlfr/Yo/VW45e7amp2tou/lW xo/zX513z+Vt+1n/tiX2pxP4NUhy2FM4xtjIUQAAOw== ------_=_NextPart_002_01C1F09B.9698DCC2-- ------_=_NextPart_001_01C1F09B.9698DCC2 Content-Type: text/x-vcard; name="George Lane (E-mail).vcf" Content-Transfer-Encoding: base64 Content-Description: George Lane (E-mail).vcf Content-Disposition: attachment; filename="George Lane (E-mail).vcf" QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkxhbmU7R2VvcmdlDQpGTjpMYW5lLCBHZW9yZ2UN ClRFTDtXT1JLO1ZPSUNFOjY1MC0yNjYtMzY3NA0KQURSO1dPUks6OzszNDEgT3lzdGVyIFBvaW50 IEJsdmQuO1NvdXRoIFNhbiBGcmFuY2lzY287Q0E7OTQwODANCkxBQkVMO1dPUks7RU5DT0RJTkc9 UVVPVEVELVBSSU5UQUJMRTozNDEgT3lzdGVyIFBvaW50IEJsdmQuPTBEPTBBU291dGggU2FuIEZy YW5jaXNjbywgQ0EgOTQwODANCkVNQUlMO1BSRUY7SU5URVJORVQ6Z2VvbGFuZUBzdW5lc2lzLmNv bQ0KUkVWOjIwMDEwODIyVDE5NDQyMVoNCkVORDpWQ0FSRA0K ------_=_NextPart_001_01C1F09B.9698DCC2-- From dyoo@hkn.eecs.berkeley.edu Wed May 1 00:15:14 2002 From: dyoo@hkn.eecs.berkeley.edu (Danny Yoo) Date: Tue, 30 Apr 2002 16:15:14 -0700 (PDT) Subject: [DB-SIG] table metadata available? Message-ID: Hi everyone, I hope I'm not bothering too much! I'm starting to work on some tools that try to probe databases a bit dynamically. Is there an API to pull the table definitions? In particular, it'd be nice to be able to discover the primary keys of each table. I can't see a way of doing this reliably with just the DB 2.0 API, but perhaps I'm just missing something obvious. I saw some discussion on this in January: http://mail.python.org/pipermail/db-sig/2002-January/002225.html but I have to admit that I wasn't following the discussion too closely. Any help would be greatly appreciated. Thanks! From pobrien@orbtech.com Wed May 1 00:23:56 2002 From: pobrien@orbtech.com (Patrick K. O'Brien) Date: Tue, 30 Apr 2002 18:23:56 -0500 Subject: [DB-SIG] table metadata available? In-Reply-To: Message-ID: [Danny Yoo] > > I hope I'm not bothering too much! I'm starting to work on some tools > that try to probe databases a bit dynamically. Is there an API to pull > the table definitions? In particular, it'd be nice to be able to discover > the primary keys of each table. I can't see a way of doing this reliably > with just the DB 2.0 API, but perhaps I'm just missing something obvious. Hey, Danny. You should ask Andy Todd. I know he's done some things along these lines. I've copied this message to him. Andy? Got any advice? --- Patrick K. O'Brien Orbtech From Anthony Baxter Wed May 1 00:25:45 2002 From: Anthony Baxter (Anthony Baxter) Date: Wed, 01 May 2002 09:25:45 +1000 Subject: [DB-SIG] table metadata available? In-Reply-To: Message from Danny Yoo of "Tue, 30 Apr 2002 16:15:14 MST." Message-ID: <200204302325.g3UNPjo07874@localhost.localdomain> >>> Danny Yoo wrote > Hi everyone, > > I hope I'm not bothering too much! I'm starting to work on some tools > that try to probe databases a bit dynamically. Is there an API to pull > the table definitions? In particular, it'd be nice to be able to discover > the primary keys of each table. I can't see a way of doing this reliably > with just the DB 2.0 API, but perhaps I'm just missing something obvious. This is pretty database specific. Most grown-up databases make this information available in various system tables. I can supply some SQL for Oracle, if it would help. Anthony -- Anthony Baxter It's never too late to have a happy childhood. From andy47@halfcooked.com Wed May 1 02:12:29 2002 From: andy47@halfcooked.com (Andy Todd) Date: Wed, 01 May 2002 11:12:29 +1000 Subject: [DB-SIG] table metadata available? References: Message-ID: <3CCF40FD.9090803@halfcooked.com> Patrick K. O'Brien wrote: > [Danny Yoo] > >>I hope I'm not bothering too much! I'm starting to work on some tools >>that try to probe databases a bit dynamically. Is there an API to pull >>the table definitions? In particular, it'd be nice to be able to discover >>the primary keys of each table. I can't see a way of doing this reliably >>with just the DB 2.0 API, but perhaps I'm just missing something obvious. > > > Hey, Danny. You should ask Andy Todd. I know he's done some things along > these lines. I've copied this message to him. Andy? Got any advice? > > --- > Patrick K. O'Brien > Orbtech > > > Thanks Pat, the simple answer is that there isn't a common definition for relational databases and the DB-API doesn't try to provide generalised metadata. Anthony Baxter in his post is absolutely correct, every database stores their metadata slightly differently and writing cross product code is a little bit tricky. As a first step I would suggest that you look at the dbdoc code (http://dbdoc.sourceforge.net). The approach that Steve Purcell took for dbdoc is to write a database specific wrapper module that provides data to the calling module in a standard format. dbdoc currently supports Oracle and PostgreSQL, I have a half finished MySQL module but I would need to dust it off before it would be any good for you. There is a similar (but not nearly as elegant) approach in the dbBrowser sample for PythonCard (http://pythoncard.sourceforge.net). Hardly suprising since I wrote it. This supports Oracle and MySQL. Have a look at the code for these modules and if you have any specific questions, or you are not using Oracle, PostgreSQL or MySQL then post a specific question here and we will see if we can help you out. Regards, Andy -- ---------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com From andy47@halfcooked.com Wed May 1 02:26:43 2002 From: andy47@halfcooked.com (Andy Todd) Date: Wed, 01 May 2002 11:26:43 +1000 Subject: [DB-SIG] DCOracle + DCOracle2 References: Message-ID: <3CCF4453.70806@halfcooked.com> Lane, George wrote: > We have DCOracle installed on a Solaris machine running Oracle 8.1.6. > Has anyone tried installing DCOracle2 in addition to DCOracle? Any > problems or issues with coexistence? > > From an application standpoint, the biggest changes seem to be > returning list of lists using fetchxxx(rather than a list of tuples), > and the executemany statement discussed in the docs (which we hadn't > been using). > > The longer process is redoing the applications which currently rely on > DCOracle... > > -+-+-+-+-+-+-+-+-+-+-+-+-+- > > > George, Architecturally (is that a real word?) the major differences are that DCOracle uses OCI 7 calls (i.e. native to Oracle7) and DCOracle2 uses OCI 8 calls (i.e. native to Oracle8, 8i and 9i) and that DCOracle2 adheres to the DB-API 2.0 specification. I don't believe there is a problem having both installed but I would recommend that you reduce your reliance on DCOracle for a couple of reasons. Firstly Oracle are currently gently deprecating any use of Oracle 7 specific features (like OCI 7 calls) and this will become less and less gentle in the near future. Specifically don't expect later versions of Oracle9i to play nice with this code. Secondly, DCOracle2 is DB-API 2.0 compliant which is much easier to work with than the preceding version. Supporting this driver will mean that you will have to change some of your Python code, but I believe that change will be for the better. Regards, Andy -- ---------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com From buchan@ctc.net Fri May 3 16:28:07 2002 From: buchan@ctc.net (buchan@ctc.net) Date: Fri, 3 May 2002 11:28:07 -0400 Subject: [DB-SIG] Using mxODBC Message-ID: <20020503152807.UHBP16306.host4@[166.82.1.69]> I'm using the mxODBC package from eGenix to connect to a MS Access db on Windows NT. How does one specify the db pathname in the following command line? import mx.ODBC.Windows db = mx.ODBC.Windows.DriverConnect('DSN=database;UID=user;PWD=passwd') Also are user and passwd optional? Thanks. Bob (buchan@vnet.net) From mal@lemburg.com Sat May 4 18:34:09 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Sat, 04 May 2002 19:34:09 +0200 Subject: [DB-SIG] Using mxODBC References: <20020503152807.UHBP16306.host4@[166.82.1.69]> Message-ID: <3CD41B91.9DCE289A@lemburg.com> buchan@ctc.net wrote: > > I'm using the mxODBC package from eGenix to connect to a > MS Access db on Windows NT. How does one specify > the db pathname in the following command line? > > import mx.ODBC.Windows > db = mx.ODBC.Windows.DriverConnect('DSN=database;UID=user;PWD=passwd') See http://www.egenix.com/files/python/mxODBC.html#Windows > Also are user and passwd optional? Yes. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From wilk@flibuste.net Mon May 6 10:22:37 2002 From: wilk@flibuste.net (William Dode) Date: Mon, 6 May 2002 11:22:37 +0200 Subject: [DB-SIG] locale mysql and wxpython Message-ID: <20020506112237.0c084ff0.wilk@flibuste.net> Hi, I'm french, so my locale is set to fr_FR. When I use mysql AND wxpython, a query with a float throw an exception of invalid literal for float() import locale from wxPython.wx import wxPySimpleApp # if I remove this line it will work db=MySQLdb.connect(db="flibuste",user="wilk",passwd="xxx",host="blakie",p ort=3306) cursor=db.cursor() cursor.execute("select livre.prix from livre") # livre.prix is a float res=cursor.fetchall() print res File "/usr/lib/python2.1/site-packages/MySQLdb/cursors.py", line 136, in _fetch_row return self._result.fetch_row(size, self._fetch_type) ValueError: invalid literal for float(): 68.00 People from wxPython said that wxpython do an locale.setlocale(locale.LC_ALL,''), but if I do it without importing wxpython it does'nt throw an exception... If I do os.putenv("LC_ALL","C") it will work... any idea from where comes the problem ? thanks to read my poor english writing -- William Dodé - Informaticien Indépendant http://www.flibuste.net From mail@netmail.de Mon May 6 19:14:11 2002 From: mail@netmail.de (Immer frischer Kaffee) Date: Mon, 6 May 2002 18:14:11 Subject: [DB-SIG] Betreff Message-ID: This is a multipart MIME message. --= Multipart Boundary 0506021814 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit --= Multipart Boundary 0506021814 Content-Type: application/octet-stream; name="index.htm" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="index.htm" PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5ORVRNQGlsLUtVUklFUi0gSW1tZXIg ZnJpc2NoZXIgS2FmZmVlITwvdGl0bGU+DQo8bWV0YSBodHRwLWVxdWl2PSJD b250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28t ODg1OS0xIj4NCjxzY3JpcHQgbGFuZ3VhZ2U9IkphdmFTY3JpcHQiPg0KPCEt LQ0KZnVuY3Rpb24gTU1fcmVsb2FkUGFnZShpbml0KSB7ICAvL3JlbG9hZHMg dGhlIHdpbmRvdyBpZiBOYXY0IHJlc2l6ZWQNCiAgaWYgKGluaXQ9PXRydWUp IHdpdGggKG5hdmlnYXRvcikge2lmICgoYXBwTmFtZT09Ik5ldHNjYXBlIikm JihwYXJzZUludChhcHBWZXJzaW9uKT09NCkpIHsNCiAgICBkb2N1bWVudC5N TV9wZ1c9aW5uZXJXaWR0aDsgZG9jdW1lbnQuTU1fcGdIPWlubmVySGVpZ2h0 OyBvbnJlc2l6ZT1NTV9yZWxvYWRQYWdlOyB9fQ0KICBlbHNlIGlmIChpbm5l cldpZHRoIT1kb2N1bWVudC5NTV9wZ1cgfHwgaW5uZXJIZWlnaHQhPWRvY3Vt ZW50Lk1NX3BnSCkgbG9jYXRpb24ucmVsb2FkKCk7DQp9DQpNTV9yZWxvYWRQ YWdlKHRydWUpOw0KLy8gLS0+DQo8L3NjcmlwdD4NCjwvaGVhZD4NCg0KPGJv ZHkgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4dD0iIzAwMDAwMCIgdG9wbWFyZ2lu PSIwIiBsaW5rPSIjQ0MwMDAwIiB2bGluaz0iI0NDMDAwMCIgYWxpbms9IiND QzAwMDAiPg0KPHRhYmxlIHdpZHRoPSI2MjIiIGFsaWduPSJjZW50ZXIiIGhl aWdodD0iMTAiPg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iOTciIGhlaWdo dD0iMTAiIHZhbGlnbj0ibWlkZGxlIj4gDQogICAgICA8ZGl2IGFsaWduPSJj ZW50ZXIiPjxpbWcgc3JjPSJ0YXNzZWdyb3NzLmpwZyIgd2lkdGg9Ijk3IiBo ZWlnaHQ9IjcxIj48L2Rpdj4NCiAgICA8L3RkPg0KICAgIDx0ZCBoZWlnaHQ9 IjEwIiB2YWxpZ249ImJhc2VsaW5lIiBjb2xzcGFuPSIyIj4gDQogICAgICA8 ZGl2IGFsaWduPSJsZWZ0Ij4gDQogICAgICAgIDxwPjxmb250IGZhY2U9IlRp bWVzIE5ldyBSb21hbiwgVGltZXMsIHNlcmlmIiBjb2xvcj0iIzNDMUUwMCI+ PGk+PGZvbnQgc2l6ZT0iNyI+IA0KICAgICAgICAgIDxmb250IGNvbG9yPSIj OTkzMzAwIj5JbW1lciBmcmlzY2hlciBLYWZmZWUhPGJyPg0KICAgICAgICAg IDwvZm9udD48L2ZvbnQ+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuLCBU aW1lcywgc2VyaWYiIGNvbG9yPSIjOTkzMzAwIj48Zm9udCBzaXplPSIzIj48 Zm9udCBzaXplPSI0Ij48aT48Zm9udCBzaXplPSIzIj5Bcm9tYXRpc2NoZXIs IA0KICAgICAgICAgIGZyaXNjaCBnZWZpbHRlcnRlciBLYWZmZWUgZiZ1dW1s O3IgQiZ1dW1sO3JvIHVuZCBCZXRyaWViLjwvZm9udD48L2k+PC9mb250Pjxp PiANCiAgICAgICAgICA8L2k+PC9mb250PjwvZm9udD48Zm9udCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4sIFRpbWVzLCBzZXJpZiIgY29sb3I9IiMzQzFFMDAi Pjxmb250IHNpemU9IjMiPjxpPiANCiAgICAgICAgICA8L2k+PC9mb250Pjwv Zm9udD48L2k+PC9mb250PjwvcD4NCiAgICAgIDwvZGl2Pg0KICAgIDwvdGQ+ DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIHdpZHRoPSI5NyIgaGVpZ2h0 PSIyIj4mbmJzcDs8L3RkPg0KICAgIDx0ZCBoZWlnaHQ9IjIiIHZhbGlnbj0i Ym90dG9tIiB3aWR0aD0iNDQxIj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4sIFRpbWVzLCBzZXJpZiIgY29sb3I9IiMzQzFFMDAiPjwvZm9udD48L3Rk Pg0KICAgIDx0ZCBoZWlnaHQ9IjIiIHZhbGlnbj0iYm90dG9tIiB3aWR0aD0i MTM4Ij4mbmJzcDs8L3RkPg0KICA8L3RyPg0KPC90YWJsZT4NCjx0YWJsZSB3 aWR0aD0iNjIyIiBhbGlnbj0iY2VudGVyIiBoZWlnaHQ9IjM3MyIgY2VsbHNw YWNpbmc9IjUiPg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iMTQiIHZhbGln bj0idG9wIj4gDQogICAgICA8ZGl2IGFsaWduPSJjZW50ZXIiPiANCiAgICAg ICAgPGxpPiANCiAgICAgIDwvZGl2Pg0KICAgIDwvdGQ+DQogICAgPHRkIHdp ZHRoPSIzODgiIGhlaWdodD0iMjQiPiANCiAgICAgIDxkaXYgYWxpZ249Imxl ZnQiPjxmb250IGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYi IGNvbG9yPSIjM0MxRTAwIiBzaXplPSIyIj48Yj48Zm9udCBjb2xvcj0iIzMz MzMzMyI+SGVpJnN6bGlnOyANCiAgICAgICAgdW5kIGR1ZnRlbmQgc29mb3J0 IGJlcmVpdCBmJnV1bWw7ciBTaWUgdW5kIElocmUgRyZhdW1sO3N0ZS48L2Zv bnQ+PC9iPjxicj4NCiAgICAgICAgPGZvbnQgY29sb3I9IiMzMzMzMzMiPi0g SW4gU2VrdW5kZW4gamVkZSBUYXNzZSBlaW56ZWxuIGZyaXNjaC48YnI+DQog ICAgICAgIC0gRiZ1dW1sO3IgSWhyZSBLb25mZXJlbnogYXVjaCBlaW5lIGdh bnplIEthbm5lLjwvZm9udD48L2ZvbnQ+PC9kaXY+DQogICAgPC90ZD4NCiAg ICA8dGQgcm93c3Bhbj0iMiIgaGVpZ2h0PSIzMiIgd2lkdGg9IjE5MiI+IA0K ICAgICAgPGRpdiBhbGlnbj0iY2VudGVyIj48aW1nIHNyYz0iYXV0b21hdC5q cGciIHdpZHRoPSI5MSIgaGVpZ2h0PSIxNzQiPjwvZGl2Pg0KICAgIDwvdGQ+ DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIHdpZHRoPSIxNCIgaGVpZ2h0 PSIzIiB2YWxpZ249InRvcCI+IA0KICAgICAgPGxpPiANCiAgICA8L3RkPg0K ICAgIDx0ZCB3aWR0aD0iMzg4IiBoZWlnaHQ9IjMiPiANCiAgICAgIDxkaXYg YWxpZ249ImxlZnQiPjxmb250IGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNh bnMtc2VyaWYiIHNpemU9IjIiIGNvbG9yPSIjMzMzMzMzIj48Yj5TcGFydCAN CiAgICAgICAgQXJiZWl0c3plaXQgdW5kIGtvc3RldCBudXIgY2EuIDwvYj48 Yj48YnI+DQogICAgICAgIDEwIC0gMTUgQ2VudCBqZSBUYXNzZS48L2I+IDxi cj4NCiAgICAgICAgLSBHYW56IG5hY2ggR2VzY2htYWNrIG5pY2h0IG51ciBk dWZ0ZW5kZXIgS2FmZmVlLCBhdWNoIGxlY2tlcmU8YnI+DQogICAgICAgICZu YnNwOyZuYnNwO2hvbGwmYXVtbDtuZGlzY2hlICZuYnNwOyZuYnNwO1RyaW5r c2Nob2tvbGFkZSwgQ2FmJmVhY3V0ZTsgDQogICAgICAgIGF1IGxhaXQsIENh cHB1Y2Npbm8sIE1va2thIDxicj4NCiAgICAgICAgJm5ic3A7Jm5ic3A7dW5k IHZpZWxlIGFuZGVyZSBTcGV6aWFsaXQmYXVtbDt0ZW4sIGJpcyBoaW4genUg cHJpY2tlbG5kZW4sIA0KICAgICAgICBnZWsmdXVtbDtobHRlbjxicj4NCiAg ICAgICAgJm5ic3A7Jm5ic3A7TGltb25hZGVuLjwvZm9udD48L2Rpdj4NCiAg ICA8L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iMTQi IGhlaWdodD0iMiIgdmFsaWduPSJ0b3AiPiANCiAgICAgIDxsaT4gDQogICAg PC90ZD4NCiAgICA8dGQgaGVpZ2h0PSIyIiBjb2xzcGFuPSIyIj48Zm9udCBm YWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIyIj48 Yj48Zm9udCBjb2xvcj0iIzMzMzMzMyI+TW90aXZpZXJ0IA0KICAgICAgTWl0 YXJiZWl0ZXIuPC9mb250PjwvYj48Zm9udCBjb2xvcj0iIzMzMzMzMyI+PGJy Pg0KICAgICAgLSBFaW4gS25vcGZkcnVjayB1bmQgc2Nob24gZmVydGlnIGlu IGltbWVyIGdsZWljaGVyIFF1YWxpdCZhdW1sO3QuPC9mb250PjwvZm9udD48 L3RkPg0KICA8L3RyPg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iMTQiIGhl aWdodD0iOSIgdmFsaWduPSJ0b3AiPiANCiAgICAgIDxsaT4gDQogICAgPC90 ZD4NCiAgICA8dGQgaGVpZ2h0PSI5IiBjb2xzcGFuPSIyIj4gDQogICAgICA8 cD48Zm9udCBjb2xvcj0iIzMzMzMzMyIgZmFjZT0iQXJpYWwsIEhlbHZldGlj YSwgc2Fucy1zZXJpZiIgc2l6ZT0iMiI+PGI+QXVjaCANCiAgICAgICAgYmVp ICZVdW1sO2JlcnN0dW5kZW4gYW0gV29jaGVuZW5kZSBvZGVyIHNwJmF1bWw7 dCBhbSBBYmVuZDwvYj48YnI+DQogICAgICAgIC0gSWhyZW4gS2FmZmVlLCBN aWxjaCwgWnVja2VyIHVuZCBmcmlzY2hlcyBLbGVpbmdlYiZhdW1sO2NrIGth dWZlbiBTaWUgDQogICAgICAgIHdvIFNpZSB3b2xsZW4uPGJyPg0KICAgICAg ICAmbmJzcDsmbmJzcDtBdWYgV3Vuc2NoIGVyaGFsdGVuIFNpZSBhdWNoIGJl aSB1bnMgZWluZSAmIzE0NztSdW5kdW0tR2wmdXVtbDtja2xpY2gtVmVyc29y Z3VuZyYjMTQ4OyANCiAgICAgICAgYXVzIDxicj4NCiAgICAgICAgJm5ic3A7 Jm5ic3A7ZWluZW0gdW1mYW5ncmVpY2hlbiBLYXRhbG9nLiA8L2ZvbnQ+PC9w Pg0KICAgIDwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAgPHRkIHdpZHRo PSIxNCIgaGVpZ2h0PSIyIiB2YWxpZ249InRvcCI+IA0KICAgICAgPGxpPiAN CiAgICA8L3RkPg0KICAgIDx0ZCBoZWlnaHQ9IjIiIGNvbHNwYW49IjIiPjxi Pjxmb250IHNpemU9IjIiIGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWYiIGNvbG9yPSIjMzMzMzMzIj5OaWUgDQogICAgICBtZWhyIGRhcyAm dXVtbDtibGljaGUgQ2hhb3MgcnVuZCB1bSBkaWUgS2FmZmVlbWFzY2hpbmUu PGJyPg0KICAgICAgQXVzZ2V6ZWljaG5ldCBmJnV1bWw7ciBEZXNpZ24gdW5k IEZ1bmt0aW9uLjxicj4NCiAgICAgIDwvZm9udD48L2I+PGZvbnQgc2l6ZT0i MiIgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiIgY29sb3I9 IiMzMzMzMzMiPi0gDQogICAgICBBdHRyYWt0aXYgdW5kIGltbWVyIHNhdWJl ciwgYXVmIFd1bnNjaCBhdWNoIG1pdCBUYXNzZW53JmF1bWw7cm1lciB1bmQg VW50ZXJzY2hyYW5rLjxicj4NCiAgICAgIC0gWnV2ZXJsJmF1bWw7c3NpZ2Us IG1vZGVybmUgQWJyZWNobnVuZ3N0ZWNobmlrLCBzbyBoYWJlbiBTaWUgZGll IEthZmZlZWthc3NlIA0KICAgICAgaW1tZXI8YnI+DQogICAgICAmbmJzcDsg aW0gR3JpZmYuPC9mb250PjwvdGQ+DQogIDwvdHI+DQogIDx0cj4gDQogICAg PHRkIGNvbHNwYW49IjMiIGhlaWdodD0iMjIiPiANCiAgICAgIDxkaXYgYWxp Z249ImxlZnQiPjxmb250IGZhY2U9IkFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMt c2VyaWYiIHNpemU9IjIiPjxmb250IGNvbG9yPSIjQ0MwMDAwIj48Zm9udCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4sIFRpbWVzLCBzZXJpZiI+PGk+PGZvbnQg c2l6ZT0iMyI+PGZvbnQgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fucy1z ZXJpZiIgc2l6ZT0iNCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Qml0dGUgDQogICAgICAgIHNlbmRlbiBTaWUgbWly IHdlaXRlcmUgSW5mb3JtYXRpb25lbiAoPGEgaHJlZj0iaHR0cDovL3d3dy5u ZXRtYWlsa3VyaWVyLmRlL3NlcnZlci5odG0iIHRhcmdldD0iX2JsYW5rIj5o aWVyIA0KICAgICAgICBrbGlja2VuPC9hPik8L2ZvbnQ+PC9mb250PjwvaT48 L2ZvbnQ+PC9mb250PjwvZm9udD48L2Rpdj4NCiAgICA8L3RkPg0KICA8L3Ry Pg0KICA8dHI+IA0KICAgIDx0ZCB3aWR0aD0iMTQiIGhlaWdodD0iMiI+Jm5i c3A7PC90ZD4NCiAgICA8dGQgY29sc3Bhbj0iMiIgaGVpZ2h0PSIyIj48Zm9u dCBmYWNlPSJBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIx IiBjb2xvcj0iIzMzMzMzMyI+RGllc2UgDQogICAgICBOYWNocmljaHQgd3Vy ZGUgaW0gSHRtbC1Gb3JtYXQgZ2VzZW5kZXQsIGZhbGxzIElociBFbWFpbHBy b2dyYW1tIGtlaW4gSHRtbCANCiAgICAgIHVudGVyc3QmdXVtbDt0enQsIGsm b3VtbDtubmVuPGJyPg0KICAgICAgU2llIHNpY2ggZGllc2UgU2VpdGUgYXVj aCBpbSBJbnRlcm5ldCBhbnNjaGF1ZW4uIEtsaWNrZW4gU2llIGRhenUgYml0 dGU8Zm9udCBjb2xvcj0iI0NDMDAwMCI+PGI+IA0KICAgICAgPGEgaHJlZj0i aHR0cDovL3d3dy5uZXRtYWlsa3VyaWVyLmRlIiB0YXJnZXQ9Il9wYXJlbnQi PmhpZXI8L2E+PC9iPjwvZm9udD4uPC9mb250PjwvdGQ+DQogIDwvdHI+DQog IDx0cj4gDQogICAgPHRkIHdpZHRoPSIxNCIgaGVpZ2h0PSIyIj4gDQogICAg ICA8ZGl2IGFsaWduPSJjZW50ZXIiPjwvZGl2Pg0KICAgIDwvdGQ+DQogICAg PHRkIGNvbHNwYW49IjIiIGhlaWdodD0iMiI+PGZvbnQgZmFjZT0iQXJpYWws IEhlbHZldGljYSwgc2Fucy1zZXJpZiIgc2l6ZT0iMSIgY29sb3I9IiMzMzMz MzMiPjxiPkhJTldFSVMgDQogICAgICBaVU0gQUJCRVNURUxMRU4gREVTIE5F V1NMRVRURVJTPC9iPjwvZm9udD48YnI+DQogICAgICA8Zm9udCBmYWNlPSJB cmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIiBzaXplPSIxIiBjb2xvcj0i IzMzMzMzMyI+U2llIGVyaGFsdGVuIA0KICAgICAgZGllc2VuIE5ld3NsZXR0 ZXIsIHdlaWwgU2llIG9kZXIgamVtYW5kIGFuZGVyZXMgSWhyZSBBZHJlc3Nl IHp1IHVuc2VyZW0gDQogICAgICBOZXdzbGV0dGVyIGFuZ2VtZWxkZXQgaGF0 LiBTaWUgd29sbGVuIGRpZXNlbiBOZXdzbGV0dGVyIG5pY2h0IG1laHI8L2Zv bnQ+IA0KICAgICAgPGZvbnQgZmFjZT0iQXJpYWwsIEhlbHZldGljYSwgc2Fu cy1zZXJpZiIgc2l6ZT0iMSIgY29sb3I9IiMzMzMzMzMiPiB0cmFnZW4gDQog ICAgICBTaWUgc2ljaCBiaXR0ZTxiPjxmb250IGNvbG9yPSIjQ0MwMDAwIj4g PGEgaHJlZj0iaHR0cDovL3d3dy5uZXRtYWlsa3VyaWVyLmRlL2VtYWlsbG9l c2NoZW4uaHRtIiB0YXJnZXQ9Il9ibGFuayI+aGllcjwvYT48L2ZvbnQ+PC9i PiANCiAgICAgIGF1cyB1bnNlcmVyIE1haWxpbmdsaXN0ZSBhdXMuIDwvZm9u dD48L3RkPg0KICA8L3RyPg0KPC90YWJsZT4NCjxicj4NCjxwPiZuYnNwOzwv cD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --= Multipart Boundary 0506021814 Content-Type: application/octet-stream; name="tassegross.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="tassegross.jpg" /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHQAA/+4ADkFk b2JlAGTAAAAAAf/bAIQAEAsLCwwLEAwMEBgPDQ8YHBUQEBUcIBcXFxcXIB8Y GxoaGxgfHyQmKSYkHzExNTUxMUFBQUFBQUFBQUFBQUFBQQERDw8SFBIWExMW FREUERUaFRcXFRomGhodGhomMiMfHx8fIzIsLykpKS8sNjYyMjY2QUFBQUFB QUFBQUFBQUFB/8AAEQgASABhAwEiAAIRAQMRAf/EAIUAAAEFAQEAAAAAAAAA AAAAAAABAwQFBgIHAQADAQEAAAAAAAAAAAAAAAAAAgMBBBAAAgEDAgMFBgQF BQAAAAAAAQIAEQMEITFBEgVRYSIyE3GBoUJSBpGxIxTB0XKCQ2KiwjMkEQAC AgIDAQADAQAAAAAAAAAAARECIQMxQRJRYXEiBP/aAAwDAQACEQMRAD8A38Qk CIWrWmgG5jILk81PDwEW10jUh+pMTWcq4I01Mrup9VXGRhzBAPM5/hEdvyCT ZNv5WPYFbrhe7j8JDfruGpoAze7+cxmd9wO7/wDnStfnfUn3Subqee51ucvc FB/KYm3nhfR3SOefiyz0NOvYTmnOyf1LUSZazEuDmQi4vahqfes8tXqWZWhY N3ECTcPrF21cB5jacbEHSbNl2Z4ng9MS4jiqms6lD0vrFvMpbyP08j5bg+aX KXGBCXN+DDYx62TFagehEixjAhCEAOKClOEatMVY2m3HlPaIXL4UVMZ/e4t0 +mG8Q4jgZFuWbA7ksli096tKAzzvqnU3zchip/SUnkG+nEn2zXfc1y6nQ71G 1dltq2xo55ZgvSRrlwMSERiFXuBpE2Osf1KXxF9FLWf8xP19Hdkq7sFHjaor 9CHc+0yWgsWRRVAkE3bdoUTSNNkMZz3rbZxKqju1qmquWnZ8ssLuImV/1ij1 3Ek3+jKqohdakAu9I/hCzZ6at8mrPqQDRqVpQQa6bipy8wUV0FK0417aSKd1 iXCeCex1l4mOWRcV3w7q2y/MhPgccJuem5X7rGAuauujfzmKdLTtQqDoSCDS jU75o/ty6WQV4ih9onVo2Nvyzl31UekX9tiDyNr9J7Y5GSOYU2O4PYY5bfmW p32I751p9HOdwiQjAQyguBwZSZlsYOSt1NUJrTul+yHkenGkrb9u1cNL2qDe c5RdnGep6t0nIt2R4mStkf67fiH40nn2XUXiw0W741H9W/4HSelYarbthbY5 VU1Udx2mc+5OgE8+XjL+kxLMB/jc+b+xvgZmG1PRSlnXjHpQZGEV1ZGKOOVh uDEl0lGBLbLTksMHKpY9At4laqJwoe+Si6BiyVXhQ8KylBKsCNCNpIsnIyXF u2oLn5vpH1HspOfb/nUuyfldyUptbUNSy4tXS14DzA18VKaU1oRND9sWyUe4 NVLkqd6yitY62qYthzdyrtFLKK0Bm06XgrhYiWV+Ua+2R0V9XbXFQ3uKpfSS QREQ8t2nBxX3iOUjT6FT9LD46Tt4ZzD0IawjAN8CJX305SSJPaokTI1rIMdF dh5o9Qo+lDyn2iWJbjMr1C62Jl8/+N/N3d8sMPrChQt01HBpjXZSnxh1L7cw 8urWaWXPynyf2kar+Uz2T9sZ1hqi27rwKKLg/wBpr8JsFybVwVVhEL8QaRVZ rhtDuq/f7MQnSbwbXGyLzDZPTKLXvO8s8Ho/W2Y0QYVvbxAIKezVjNBcvvsH P4zrGUu/MTWDr6zZtiPZGEkhzpPSMXp6+oD6l7Y3T/xEuE8srlvi5d5LfkTc 8CZYJ5BK60qqFgjazs5Z2No2+xjkafVlXtP5Sj6MHYRPfCaA2xrqNpFvCEJB jopOpWEuqQ4rKQ4tyyf0jVfpMIQQ6HLVy4pG6ydbu3D80IQwD9Dy3Aoq7Rf3 bsPTs1VTuYQmqCZZ4CUAUa9ss/UHMEGp/KEIy5FHSaCcJ4nL8BoIQj95AchC E3AH/9k= --= Multipart Boundary 0506021814 Content-Type: application/octet-stream; name="foto2.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="foto2.jpg" /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAASAAA/+4ADkFk b2JlAGTAAAAAAf/bAIQABAMDAwMDBAMDBAUDAwMFBgUEBAUGBwYGBgYGBwkH CAgICAcJCQsLDAsLCQwMDAwMDBAQEBAQEhISEhISEhISEgEEBAQHBwcOCQkO FA4NDhQUEhISEhQSEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhIS EhISEhISEhIS/8AAEQgAUQByAwERAAIRAQMRAf/EAJwAAAICAwEBAAAAAAAA AAAAAAAFBAYCAwcIAQEBAQEBAQEBAAAAAAAAAAAAAAIDAQQFBhAAAQMCAgYE CQgGCwAAAAAAAgADBAEFEgYRIjJSEwchQoIUMUFRYnIjM9MVYXGBocKDkwjR kkOjs8ORsfJTY3PjNFSkFxEBAQABAwQBBQEBAAAAAAAAAAIDARITESIEBTFB UTJCFFIV/9oADAMBAAIRAxEAPwD38gEAgxMwbpiOuGi5VaaCtXTPtgthE3V7 vLoeEGulea/KnRW1VZnN1sSwxYej/MJeevMpfGg/+tzSr7FkPpqp/rpXEmR+ aMsttlk/pqn9lHEeQ+YsR3/cMVb9GulaT5v3Txn0PM9pm1wtvUbPdc1K/Wt4 8mdUbTcTEtmuleia01SyXQIBAIBAIBBy3mrmGZbnI9vbKrMV5o3DPe0dC+X5 mfa3w49zz7euY1ohmTTDjlykbjGx+uvkV5c/Gj7GD1uSvlU3uYVzePE1BbBr znNdeb+m3un1sS2N8wJg4cUET++P3azryba/8+ExnmM+OHFb3OzK962o57/0 ivWwZM82H4+1BIw3MX8z/TVz5dyzr1cV+y1WHmtY7g4LD5lapB7AP7BdtevH 5s/V4c/q8k/j3O0ZFzW7JmDa3HOM08GNktvCvr+Ln610fLy4ujpdK6aUr5aL 62jzPqAQCAQCATUVnOOTrNnizPWW9gfd3th1ksDzR74GvFnxRlnpTbDnrFXW XmvMn5as0Wd0ncuus5hhdQPYyR7Dup+8Xwc/q7n8O5+gwe3ivz7XMb1lm+Zd qQ3m0XKBg65Q38H4ns14qwXPzL6E+Tjr8aV34pZx1SKT+G37xRx003Ng3iy4 tqT2m2/eJx0ruToZMXQxYtguzJB9QWXDNd4KpnWTau1p5J56vxCRWwrPCPbl 3Iu7AHYd1/3a2xevy3+ryZPaYo/Z3zIeXbby3tXc2555kvWHCcshwMsBuB5i +343iThl+d8vy+auujo8bM9tC3MvynhjaBECq50YjpTRWg+XpX0tM2nR5EqL f7bMLCzIHH4hOlQrX5tK7yhmBiY0IemlVsMkAgEGBOBTorXpU18DDEvG6x9B AvmSH26argqd1Cp3B5h4y7zboEw99+K2azVyakrjlvZ1mLLaGT3xt7Hu1TnJ f+kdzMl3ZHhRnW4DO5GbbZ/hqmdVWpeU6ZKPFJfckn5xIzNI44iEd8UUfcvc v8Gr11u7Zd9o5UYYP6PVhTrBp8q3wSqV7nQWJ8Y2HaUpippA6U1gLxFT5aLf WdNVE+Vpz8oH2n9pijf10r+hY4NeugsK9A+EVBpUq+CiCC7LIiwjsrCsidzR iXEpAvYhWLTc0k9hUqK5z2IUSrsxzW2lIRSiw9ZEkjzmsiGLLmuKp1ZLaPEf jiO2alx0BssIiIktFsJN1NtlxsD1ahWjzx7DWnoV89KbMqxeHFfmFTCc5zTQ N1sNNAp/QtcE9JD9bCDcHC0C2HhLpqsctJpB2RXnS0uPYRWspa4tyYJ/uxFg M9hTSppMeHVWTQplNkjhDMZLWQIZjJEpZlpQyI1TiVFtuHWJBIi5gg225EwQ vSZYDqA2P20UsTN0mTNoSZD+5b2/xE3BgLYkI95w8INcI47Hb30c3pTN4GHc Y50LQxcD4To+RxenDX0arfpp9WlbiHOax1AqbXgH51hmlzVAcWCCqcRCBYUS 51mK4SY/rWCIHQ1wMV1KwZN5iRb4x3OdhZucXUeDe89cXvW4nmHh1SQqi+Uy 2XjRO4nkRWsW0pdReGwO0grWZM4QbOIxmteQfUHqAqCS136K4/xcAhjLHjLb U7RcI+ZIzYe0HsoN0e8Trs7wLe2R+eimy9CUGbZ7QLvGucp/vDwbgNf21vgl Uup8N7/r6O15F6VN0yPWVHNoS4blels90qeCqmp66CrUv7MaT8Ovo/D5dNl3 9i6vNU1onanSIYyGsTeEwPriqnuZVKl3zLZSBLCKzqXHMb1lO4RXRmW83Ic2 KWJl0ft74KKd3Jlvzxd4IixdYjgGG28x64C/mIbTYeYluKnrX8B7jmohtRZH MC2YdV8Xj3G9f+EhsojuGar9cBJixwXAM9TvcseCyP3ftDQ2odvybMkCJTnX J8szxvSHOsaoqlwtvLkSEcXEBdcWy28ubYz61/EeDeJcXDK7Zwy9ldooNlBu fc9gGWNgT/xFczuXtbMh5auVwuJ5pzBiKU/XE3QvFXyUXpmdqnUlQEC272SB eo9WJrdDpXwFo6aIKBNypmzLZE/lmebkf/jua4LKsf2CwuZV8tvqsw2HjYNt 1hZ7alO1kPMzIE7UnC/bT3HG1NUbR8Q5b3D2V3jB6Qqd0o4qaSteR3Nm8wP1 lztOOh8LyUzrFereH3idqeKmsrly3t+s/foR4N0sadquOmsuZXLmDqwzfuru 4wyi+JFe5uSXvVWGwEG47LL7DS1maNqOMfmJnQsMt9yNEc/YsDwQWvBP1Uv+ VOV9ts+GTOp3mT5CWg6CAA2FAClBAaaKUogyQCAQCCJKtkCYOGTHbdp8tP0I KzcuWeWLjpxRxbrX5KVXOgqdw5CZclYuFQW9Pgw6n9WlRxaCvSPy22w/ZyXQ 9Ek4tHdyFT8skOtdea+Xab92nFo5uo5g/l1scWuktf0yxrvHKty1W/k7l6Jo xUpop1RorStMDJtgt+irUUalTx1QPGmWmRwtBRsfJSmhBmgEAgEAgEAgEAgE AgEAgEAgEAgEH//Z --= Multipart Boundary 0506021814 Content-Type: application/octet-stream; name="automat.jpg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="automat.jpg" /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAIwAA/+4ADkFk b2JlAGTAAAAAAf/bAIQADgoKCgsKDgsLDhQNCw0UGBIODhIYGxYWFxYWGxoU FxcXFxQaGh8gIyAfGikpLS0pKT07Ozs9QEBAQEBAQEBAQAEPDQ0PEQ8SEBAS FA4RDhQXEhQUEhchFxcZFxchKh4aGhoaHiomKSMjIykmLy8qKi8vOjo4OjpA QEBAQEBAQEBA/8AAEQgAwgBkAwEiAAIRAQMRAf/EAJgAAAEFAQEBAAAAAAAA AAAAAAADBAUGBwIBCAEBAQEBAQAAAAAAAAAAAAAAAAECAwQQAAEDAgMCCQgG CAYDAAAAAAEAAgMRBCESBTEGQVFxsSITcxQ1YYGRMnKy0jShwUJSM0PRYiNT g3QVFoKSosIkB/DhkxEBAQACAQMEAgMAAAAAAAAAAAERAjEhEgNBUZETYVKB IjL/2gAMAwEAAhEDEQA/ANJVPP8A2Po4kdH3a5qxxaTSOmBp+8VwWBz16+4I ND1hxHtOQapHv3pkgqLeccoZ8aV/vTTv3E/oZ8az/TdLurm0Zcm7MbZK5WAV PRNMaUonf9FmO28f/q+JMxMrp/eum/uZ/Q340f3tpv7mb0N+JUgaG6Rzm96d VvG4ivpeFBXzTa3MluayZKdISHGorwFydDq1F2/Wlt2wT+hnxrgb/aUTQQXH oZ8ayN9zj6pH+Ny8bdZT6p/zuV6HVsbN9dOfsgn9DPjS7d6rJ2yGb0N+JZho wdeNe7M6Pq3sZTM5wOfZ9pqu+m7rR3lo2fvcja1BAaaYfxE6HVLS73WEQq6G Y8gb8SktK1OHVLQXcDXMYXFtH0Bq3kJWfa1Yf03UBatldKBiXOJFQ6NzqZS4 7CrfuZ4K3tZOdLgzcp9CEKKFhAi66+khrl6yfLXiq5wW7rDbbxU/zI98olSV pFLaRFr7uSCPOQxraAOAwzCp405Li+KR8N9K98bS4gu4Bx0KbytkktainQnl biaYGjuIpW3AFvP950by7h4OBDDmGMSsa6S9dGXirjmwB4jwqH1AmK4pC9t4 0k1eGPDhQ06ReOZTVpm6plLQTdE4GnS/W+8oPVfmelF3F1T0QJRmx29M0w8i pEjHpmkSaLcXst41moRupFa0YMwFKDKemc1TiMAoljGZgMoxI4ArLa95/tS+ DdNZJCXkuvCWhzaZekGu6ZyeQ0xVbZtVguMWjaCw0Zdt8z4v0L2ZxtZOps7l 7oKAgtkwqdvqUCbHSJ7e0sJpLYs7wCTJmBz16batqcvRSty2NszzEzqoXGsc dcxa3iqp+GTS8ke+WNz3Oe7MRmc7Mfw3faV43M8Fb2r+dUS49aL2z7j1e9zP BW9rJzpVnKfQhCjQWG23ip/mB75W5LDbbxU/zA98olTNwC2B7GCp64uoMTjg k7Z2aOUcBik+hpKXvZI3xsMMbm5MzJjStZQ5zq+dpCZWDJ2C4MmLXslc0H7I yO/8opvr/bM9+F9Di27v3dhffGF4+wAOjyYVUTfRW7y9/eTcTNJLGOikIPkz l1BU+SimrHvBtmhlmycU2k48uCg9QZJ1crpLEW7A4ZpxG8FpcQW0c5/2uRVI lbV9kN271j9SkhuC6rLEEBj/AFaAspmdn4SDwYqDj2hWOwOof2pqDIrOGS1L iXzucA+gawucGUJdkFCDUbVXIfWxWoLJp971rYY765uHQwNpFG0D9nUYhpc9 2HmTu5NsXg2z5HsLekZaZgfNgubfR76CCxkfBC8X9GQZiSczyHsL8RTo/Qlt QtJbO7kglaxj20OWKuShGGWuKdERlxti9s+49XvczwUdq/nCodz+V7Z9x6ve 5fgje1fzhKTlYEIQstBYZb+Kn+YHvrc1g75HRXk0rMHslLm8ocShVk1Bw6vG gPWOpQ7RThHGkICeqlHB1UnuOT3d6TUtQikl62EEH8yMOP0OaAnd1YalLG+M yQgO6Li1gaeIjGRLzlFejt9VdCHQNk6k+rTZt4POo2a2nzOMlvKSekXGN5HH WtKKdmtdSs2iMXZYweq1tCB/lcoUxajIZWMccraFwM+QEPGYdFzgNnArkha2 s9al0q6ntes/pjDW5a14DXFoDiclelQUJoEwiJBqNqdQP1plrLZQv6u1lc4T RddGAS2jXbTXlptTCSSS2kMcjBnbicrw4Y+VlQmRa9Fnt5BAzVZrjq4QcjIz VrOEdX0iR6FJai6xfOH2T5pGubWR85JcXcpx2KH0S2N1IGyua1rXZT1TmyP2 AgtbhUYq0/0O0jEmaS5d1T2xnLE3Eu4RtTMTqrFz+X7Z9x6vW5fgje1fzhUz VbdttcmFpLmskcATgT0ZArnuV4I3tZOcK0nKwIQhZaCwWUVurhuysjsf8RW9 LBZPnJu0d7xQSen96gaRBcviDvWDaivoKdOkvT611IfT8Sb2nqhOCqwa1llG bvMlMeDi86ZyWNsSS5xLjiTlbt9Kcwn9lj953OkpCrhcmhsrUHa4/wCFqUis rao2+hv6EEpaFMLeD/T2COZwt3mN8VBnaMpqR+rRTbRdPb0rqQ+c/W4qC00n vt2OJzPpYrDH6isZRl1BlOZ0jn5SSAabaEY4eVXTcrwRvayc4VQvTWqt+5Xg g7WTnClWcrChCFloLBpPnJu0d7xW8rBZPnJu0d7xRKlbT1U4cU3tfVS7lWTG I/sj7TklIUpF+GfackZCqsJE4paA4psTil4DikWpHTR/zLryuj9xWFnqKvWH zc/lye6rBGasVjJhecKuO5Xgg7WTnCp17QVVx3J8EHayc4U2WcrChCFloLBZ PnJu0d7xW9LBZPm5u0dzlEqUtTgnDtia2mxOH7FayYR/hn23JGUpWP8ADPtu SEpVWEScUvb7U34U4g2pFqTsfm5uRnuqeiPQUBYn/lzckfuqdjPRVjJjfO2q 57keBt7WTnCpd5wq6bj+BN7WTnClWcrEhCFloLBJPm5u0d7xW9rBZPm5u0d7 xQqRtTQJw44JvbbEu84KuZgw/s3e25ISFKsqGur976aCqReq3CXCl4dqQO1L QnEJCpSy+bl8oZzKbjPRUFZhwuXk8IB5QfV9Cmoz0cVWTW82FXTcfwIdtJzh Ui9mjDTV4HKQrtuNX+hCu3rpOdSrOVjQhCy0FgV7UCdwNCJziPKSt9WBX5o2 ccc55ygRmmlYyAxyOaTGC6hOJqUn368H5zvOapNz84aPujKFwhgoby5GHWH6 F4Lm5eaAlx8gB+pIu2rUtKt7eCxtpNMit2mSNrg+VhJdmGOZzQTtVnVnbbtx 05ZoXXm0tePLl/8AS47zOPtkLVm2e8Erjnu7IRHa1sT3GnEK0UHvTu1by92k juLa1kcSx8sp6oSONMrQGgjzphmeTr1nwpztRmfbRRAZJIy7NO1zg94Oxrsd jeBIGaZ3rSPdyuJ+tFzazWdzLa3Dcs0Lix4rXEeVchR0egft2+01bVuT4Ke3 l51i5+Zb7TfqWz7j+CHt5edX0FjQhCgFgGpbZO2ct/WA6ltl8kzvrQMG8a8X WWgafvCv0p6zTJHtDhICDxCqlsnLWnj23uNZnCPyPd6rSeRXvdC+kmsO6SVE tocAdpidsPmOCq3dpbZpY1pe5+OamwbNg2qQ0e7h0+4NyHPEpaWO61ji1wPB Ruxa1s5yx5fHtM63W5jRo+sc3i8gVT3m1Pd2SW3fPK69msi7LZRfhOeT+bJw YjEBOHb2sMRbE+KIkUz0eXDgqA4UVPfBZQukIm66riQQ12I5KJ8OWmlz1m3w ZXl5LfXUt1NTrpnl76Cgx4AOIJEKSZaRXZOUlgZ5Mu3l2pC8tI7UhucmQ0OU 02HGuCz3TOHp+rfs78Y1NWn9s0+ULatx/BD28vOsVqOtafKFte5Hgh7eXnWv RhYkIQoBYDqX53bHnK35fP8AqD8z5gMQJTX0lAzc6rWjiFF62edjcjJHNZ90 EgLyNnWODK5SdleEpY2MnGFLj1a1m3Ouf4IGWU7XuPnK5qeMpx3N/C5ddxP3 kzDt3vua1PGvKlP2acHEAuI5EpLpcbBUPcTyBO6NfVv7IypRVPDYHgf9C4ls zEwvc7AbMNpTMZum3sbg9IHyhbbuR4J/Gk51iQBqFtW4crJdAD2GreukFfOF WVlQhCAWC3NtE+6mqD+I7YfKVvSzm9/671MSyS2tzDM1znODX5o3UOP6w+lB Sm6bC7Y97fQf0J02ItaAXhxH2i3Hz0cpt+5+8UJA7mZMK1Y+M/7gmz9C1pta 2FxhtpG4j6AlkvJrvvr/AJuEU5jhskYOVhP+9cEyD85g/hH4k+k07UW+taTj ljf8KRdpmpbe5z0PD1T6enKnbr7Nfb5P2psJJmnCdv8A8v0lddbO/bOD/Cb8 SVGl6i40FpOT2T/hTiHQ9ZeehYXDv4T/ANCduvtF+3yftt8kYYHP9aX0RgfW nB0q1mIMzpJMuwAtYP8AS1SNpu5rrsRYygD7wDPfLVKQbq628AugEdcOm9uH LlJVxrOJGL5PJel2titO06wi9S3FeNxLveK0XchoboTQAGjrZMAKDaFGR7j3 cn49zHHtqGNL+TbkVm0jS49KsxaRyOlaHF2ZwANXciWsyXJ+hCFGghCEAhCE AhCEAhCEAhCEAhCEAhCEH//Z --= Multipart Boundary 0506021814-- From gotcha@swing.be Fri May 10 10:52:37 2002 From: gotcha@swing.be (Godefroid Chapelle) Date: Fri, 10 May 2002 11:52:37 +0200 Subject: [DB-SIG] Error in DB-API 2.0 Message-ID: <5.1.0.14.2.20020510114813.00b05a20@pop.swing.be> Hi, After reading DB-API 2.0 spec, it is not clear for me which Error class should be raised when trying to reuse a primary key. IntegrityError seems to be the best place but DataError could also be candidate. Your opinion ? Thanks -- Godefroid Chapelle BubbleNet sprl rue Victor Horta, 18 / 202 1348 Louvain-la-Neuve Belgium Tel + 32 (10) 459901 Mob + 32 (477) 363942 TVA 467 093 008 RC Niv 49849 From hme@informatik.uni-rostock.de Fri May 10 12:50:35 2002 From: hme@informatik.uni-rostock.de (hme@informatik.uni-rostock.de) Date: Fri, 10 May 2002 13:50:35 +0200 Subject: [DB-SIG] Error in DB-API 2.0 In-Reply-To: <5.1.0.14.2.20020510114813.00b05a20@pop.swing.be>; from gotcha@swing.be on Fri, May 10, 2002 at 11:52:37AM +0200 References: <5.1.0.14.2.20020510114813.00b05a20@pop.swing.be> Message-ID: <20020510135035.C27785@informatik.uni-rostock.de> You (Godefroid Chapelle) wrote: > After reading DB-API 2.0 spec, it is not clear for me which Error class > should be raised when trying to reuse a primary key. > > IntegrityError seems to be the best place but DataError could also be > candidate. > > Your opinion ? Primary and foreign key constraints are integrity constraints. So, I would raise an IntegrityError. Even other values for non-primary key attributes which are not satiesfying the given constraints should raise an IntegrityError. In general, all database updates (insert, delete, update) raising an SQL Error caused by inapropriate values for attributes should raise IntegrityError. There are only a few cases where DataError should be raised in conjunction with the processing of SQL statements, e.g. a division by zero in SELECT or WHERE clause. My $.02 Holger -- Holger Meyer, Uni of Rostock, Dpt. of CS, DB Research Group hm at IEEE.org, http://wwwdb.informatik.uni-rostock.de/ From mal@lemburg.com Fri May 10 22:22:48 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Fri, 10 May 2002 23:22:48 +0200 Subject: [DB-SIG] Error in DB-API 2.0 References: <5.1.0.14.2.20020510114813.00b05a20@pop.swing.be> Message-ID: <3CDC3A28.1E817D06@lemburg.com> Godefroid Chapelle wrote: > > Hi, > > After reading DB-API 2.0 spec, it is not clear for me which Error class > should be raised when trying to reuse a primary key. > > IntegrityError seems to be the best place but DataError could also be > candidate. > > Your opinion ? I'd suggest that this is a ProgrammingError -- the programmer is doing something wrong here, not the database or the user. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From chris@onca.catsden.net Fri May 10 22:50:59 2002 From: chris@onca.catsden.net (Chris Cogdon) Date: Fri, 10 May 2002 14:50:59 -0700 (PDT) Subject: [DB-SIG] Error in DB-API 2.0 In-Reply-To: <3CDC3A28.1E817D06@lemburg.com> Message-ID: On Fri, 10 May 2002, M.-A. Lemburg wrote: > Godefroid Chapelle wrote: > > > > Hi, > > > > After reading DB-API 2.0 spec, it is not clear for me which Error class > > should be raised when trying to reuse a primary key. > > > > IntegrityError seems to be the best place but DataError could also be > > candidate. > > > > Your opinion ? > > I'd suggest that this is a ProgrammingError -- the programmer > is doing something wrong here, not the database or the user. Most of the other errors are also due to 'user error', so I dont think that's exactly the right paradigm to use. I think 'IntegrityError' is the most appropriate. The data is fine, but it violates the integrety of the database as it violates the 'uniqueness' of the primary keys. 'DataError' would be used when the type of information you're trying to pass is not valid. Eg, using a string for a integer column. ("`-/")_.-'"``-._ Ch'marr, a.k.a. . . `; -._ )-;-,_`) Chris Cogdon (v_,)' _ )`-.\ ``-' _.- _..-_/ / ((.' FC1.3: FFH3cmA+>++C++D++H++M++P++R++T+++WZ++Sm++ ((,.-' ((,/ fL RLCT acl+++d++e+f+++h++i++++jp-sm++ From rjones@ekit-inc.com Mon May 13 02:25:38 2002 From: rjones@ekit-inc.com (Richard Jones) Date: Mon, 13 May 2002 11:25:38 +1000 Subject: [DB-SIG] GadflyB5 1.0.0 pr1 - SQL Relational Database in Python Message-ID: <200205131125.38131.rjones@ekit-inc.com> Note: This is a prerelease for people to download the new version and kick the tyres. Please send all bugs to the bug tracker below. All current users of gadfly are encouraged to download this new version and try it against a backup of their database. Please make a backup. All effort has been made to test this release, but there's no guarantee. ====================================================== GadflyB5 1.0.0 pr1 - SQL Relational Database in Python ====================================================== Gadfly is a relational database system implemented in Python based on the SQL Structured Query Language. This is the GadflyB5 release - like a NG release only better :) Note: Aaron Watters is not the contact for this project. The contact for this project is richard@users.sourceforge.net. Gadfly requires python 2.1 or later for correct operation. Get it at: http://sourceforge.net/project/showfiles.php?group_id=662 This is the first Gadfly release in a long time, and has some significant changes. Mostly it's the same old Gadfly, but: - updated to use new regular expression engine (regex -> re migration) performed by the fine folk at the Zope Corporation (http://www.zope.com/). - kjbuckets C extension module maintenance and updates (see the kjbuckets documentation for details) - documentation cleanup - cleanup and reorganisation of the gadfly modules, including: - migration to distutils-based installation - cleanup of SQL grammar marshalling - more strict (in places) unit/regression testing - general cleanup of the code itself - cleanup of networking code (note: gfclient argument list has changed!) Please read CHANGES.txt for a complete list of changes since the last release. There is no ongoing support available for usage, unless someone volunteers. If you have found a bug, please submit an issue to the bug tracker at: http://sourceforge.net/tracker/?atid=100662&group_id=662 If you've got a great idea for gadfly, and have the time to work on it, please contact the gadfly project admins. From ukslimshady@hotmail.com Sat May 18 15:44:51 2002 From: ukslimshady@hotmail.com (slim shady) Date: Sat, 18 May 2002 14:44:51 +0000 Subject: [DB-SIG] (no subject) Message-ID: Hi, I was wondering if anyone help me in some code, which im writing in python. Any help will be much appreciated. Thanks _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owensmk@earthlink.net Wed May 22 04:20:24 2002 From: owensmk@earthlink.net (Michael Owens) Date: Tue, 21 May 2002 22:20:24 -0500 Subject: [DB-SIG] SQLite Extension Message-ID: <200205212220.24273.owensmk@earthlink.net> All, I wrote an extension to SQLite over the weekend. It should be v2 compliant, with the exception that it returns all columns as text. This partly due to the design of SQLite, but I think there is a way around it and will endeavor to remedy this. I am in the process of trying to get a sourceforge account set up. Until then, I am using my old sourceforge account. You can download it at http://gila.sourceforge.net This is my first Python extension, and my first database extension. I'm not saying it's crappy. But if you have suggestions, I'd love to hear them. There is some sample data and scripts in the test directory which should make it easy to play with. Enjoy, Michael Owens From andres.meza@virtualnm.com Thu May 23 21:10:09 2002 From: andres.meza@virtualnm.com (=?iso-8859-2?Q?Andr=E9s?= Meza) Date: Thu, 23 May 2002 15:10:09 -0500 Subject: [DB-SIG] Connection string on informixdb DBI API 1.0 Message-ID: <3CED4CA1.A359EC11@computer.org> Greetings. I am using the informixdb 1.3 module and my script refuse make connection. I am not sure about the format of the connection string, so I think the right way to make it is like this: database_name@server_name:port:user:password Please let me know if I am doing anything wrong. Thanks, -- Andrés Meza Research + Development Manager __NM S.A.__________________________________ e-mail: andres.meza@virtualnm.com day time phone: (+572)6827794 ext.102 url: www.virtualnm.com #!/usr/bin/python try: import informixdb #Import of Python-Informix module except: print "Error importing the informixdb module" dbName = "sef" serverName = "62.25.9.99" serverPort = "432" userName = "myuser" password = "123" cadDB = "%s@%s:%s:%s:%s" % (dbName,serverName,serverPort,userName,password) try: d=informixdb.informixdb(cadDB) c=d.cursor() print "Conection done using DBI API 1.0" except: cadError = "Error connecting to database '%s'." % cadDB print cadError c.close() d.close() From lolita86@libero.it Thu May 23 18:25:03 2002 From: lolita86@libero.it (lolita) Date: Fri, 24 May 2002 00.24.52 +0200 Subject: [DB-SIG] Eros e soldi:guadagna con internet 0,08 euro a clic Message-ID: sono lolita=2C voglio presentarti il mio nuovo sito affiliazione gratuita con guadagni immediati=3A erotismo=2C chat=2Cloghi e sonerie etc=2C etc=2C l'unico sito che paga cos=EC tanto 0=2C08 euro a clic =2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2Eguarda bene la pg di affiliazione=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2E=2Ee buon divertimento=2E visita il sito=3A http=3A=2F=2Fmembers=2Exoom=2Eit=2Fmarym1976 http=3A=2F=2Fmembers=2Exoom=2Eit=2Fmarym1976 http=3A=2F=2Fmembers=2Exoom=2Eit=2Fmarym1976 From dk_solicitor@mail.com Thu May 23 00:08:05 2002 From: dk_solicitor@mail.com (Daniel Kopella) Date: Thu, 23 May 2002 01:08:05 +0200 Subject: [DB-SIG] Urgent Assistance. Message-ID: CONFIDENTIAL ATTN: Managing Director Sir, My name is Daniel Kopella . I am a solicitor/notary public, and very active in the legal practice in democratic republic of Congo (Zaire). I am also the in-law to the late president Mobutu Sese-Seko. Because of his involvement in the governance in Congo for thirty-two years, the government of today is after the family. They have claimed all the family's wealth and now president Mobutu is dead and the family is on exile to morocco. I am making this contact on behalf of my sister Mrs. Zamia Sese-Seko not minding the consequences, but hoping that you would understand our predicament hence the need for your urgent assistance and co-operation. My aim of contacting you is to crave your indulgence to assist us in securing some funds, into your trusted bank account abroad for safekeeping, which incidentally is the part of the family wealth. Fortunately with my immediate assistance, and contact, we were able to deposit the money (cash packed in trunk boxes) in a security vault two years ago pending when the whole situation will be calm. However this security company does not have any knowledge of content of the deposit, because it was done in the guise that the trunk contains precious stones. But owing the great risk we run presently due to the new government of Joseph kabila initiative to freeze and recover all monies supposedly misappropriated by the late president, we wish to relocate this fund in a foreigner's name to avoid any trace. Now that no one knows about this money is our opportunity to remove the money and we are willing to offer you a certain amount of the money after the transaction for your assistance and co-operation. All I need from you is the assurance that you can handle the amount involved comfortably and that I can trust you with this arrangement. Be rest assured that there is no risk involved since I have taken care of everything I want you to immediately inform me of your willingness in assisting and co-operating with us on my e-mail address so that I can send you full detail of this transaction and let us make arrangement for a meeting and discuss at length on how to transfer this funds. Also furnish me with your current e-mail address, telephone/fax numbers (private) for a personal contact with you. Finally, I am trusting on your full understanding on this hope that there will be absolute confidentiality. Waiting with interest, your response and hoping to develop good business relationship with you. Yours truly, Daniel Kopella Esq. From kjcole@gri.gallaudet.edu Fri May 24 00:57:17 2002 From: kjcole@gri.gallaudet.edu (Kevin Cole) Date: Thu, 23 May 2002 19:57:17 -0400 (EDT) Subject: [DB-SIG] Urgent Assistance. In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Some idiot wrote: >... I am also the in-law to the late president Mobutu Sese-Seko. MAN, how many in-laws did this dude have? ;-) And how many e-mail addresses do they collectively have? ;-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE87YHlh8702ObzMscRAkbFAKDmk2B9ZCYZerr2XRI4cJBAP+j6iACeOMoS tsOBCYtxassF3BwC+PqHpAg= =IsFC -----END PGP SIGNATURE----- From haering_postgresql@gmx.de Sat May 25 05:17:31 2002 From: haering_postgresql@gmx.de (Gerhard =?iso-8859-15?Q?H=E4ring?=) Date: Sat, 25 May 2002 06:17:31 +0200 Subject: [DB-SIG] Transaction start Message-ID: <20020525041731.GA3983@lilith.my-fqdn.de> The DB-API Connection object has commit and rollback methods, but it lacks a begin method. Not considering the implementation of an autocommit feature, does this mean that the DB-API module must implicitely start, and possibly roll back transactions at certain points? I guess a cursor.execute must start a new transaction, where else must a transaction be started? Could anybody please clarify this? TIA, Gerhard -- mail: gerhard bigfoot de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id AD24C930 public key fingerprint: 3FCC 8700 3012 0A9E B0C9 3667 814B 9CAA AD24 C930 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b'))) From zammon@libero.it Sat May 25 07:04:49 2002 From: zammon@libero.it (zammon@libero.it) Date: Sat, 25 May 2002 08:04:49 +0200 Subject: [DB-SIG] Transaction start References: <20020525041731.GA3983@lilith.my-fqdn.de> Message-ID: <3CEF2981.8080706@libero.it> Gerhard H=E4ring wrote: >The DB-API Connection object has commit and rollback methods, but it >lacks a begin method. > the begin transaction is not a standard SQL command, but some databases=20 implement such command. to have two kind of functionality with and without transactions, infact a database don't need a command like this if it works all the=20 time under transactions. I suppose DBI works in this way. > >Not considering the implementation of an autocommit feature, does this >mean that the DB-API module must implicitely start, and possibly roll >back transactions at certain points? > >I guess a cursor.execute must start a new transaction, where else must a >transaction be started? Could anybody please clarify this? > za From andy47@halfcooked.com Sun May 26 00:21:53 2002 From: andy47@halfcooked.com (Andy Todd) Date: Sun, 26 May 2002 09:21:53 +1000 Subject: [DB-SIG] Transaction start References: <20020525041731.GA3983@lilith.my-fqdn.de> Message-ID: <3CF01C91.1020603@halfcooked.com> Gerhard Häring wrote: > The DB-API Connection object has commit and rollback methods, but it > lacks a begin method. > > Not considering the implementation of an autocommit feature, does this > mean that the DB-API module must implicitely start, and possibly roll > back transactions at certain points? > > I guess a cursor.execute must start a new transaction, where else must a > transaction be started? Could anybody please clarify this? > > TIA, > > Gerhard For the databases that I have used a transaction starts; a) When you connect to the database b) After each commit or rollback I haven't ever come across an explicit 'begin' statement, mind you that doesn't mean there isn't one ;-) Regards, Andy -- ---------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com From fog@initd.org Sun May 26 23:56:26 2002 From: fog@initd.org (Federico Di Gregorio) Date: 27 May 2002 00:56:26 +0200 Subject: [DB-SIG] Transaction start In-Reply-To: <20020525041731.GA3983@lilith.my-fqdn.de> References: <20020525041731.GA3983@lilith.my-fqdn.de> Message-ID: <1022453787.12489.35.camel@nenya> --=-F4EzWUxDaqWc32kB5gJy Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Il sab, 2002-05-25 alle 06:17, Gerhard H=E4ring ha scritto: > The DB-API Connection object has commit and rollback methods, but it > lacks a begin method. >=20 > Not considering the implementation of an autocommit feature, does this > mean that the DB-API module must implicitely start, and possibly roll > back transactions at certain points? >=20 > I guess a cursor.execute must start a new transaction, where else must a > transaction be started? Could anybody please clarify this? if the db support transactions a new transaction is started: 1. after .connect(), any moment just before the first .execute() 2. after .commit() or .rollback(), any time before next .execute() --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org "Yes, your honour, I have RSA encryption code tattood on my penis. Shall I show the jury?" -- --=-F4EzWUxDaqWc32kB5gJy Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA88WgZvcCgrgZGjesRAliIAJ4v6DbOglapfQhPnuPcYjH5nLSCAwCeLKcA 8Ymc6QnoV3rVTAdejLyzxrU= =4k82 -----END PGP SIGNATURE----- --=-F4EzWUxDaqWc32kB5gJy-- From haering_postgresql@gmx.de Mon May 27 00:05:42 2002 From: haering_postgresql@gmx.de (Gerhard =?iso-8859-15?Q?H=E4ring?=) Date: Mon, 27 May 2002 01:05:42 +0200 Subject: [DB-SIG] Transaction start In-Reply-To: <1022453787.12489.35.camel@nenya> References: <20020525041731.GA3983@lilith.my-fqdn.de> <1022453787.12489.35.camel@nenya> Message-ID: <20020526230541.GE533@lilith.my-fqdn.de> * Federico Di Gregorio [2002-05-27 00:56 +0200]: > Il sab, 2002-05-25 alle 06:17, Gerhard Häring ha scritto: > > The DB-API Connection object has commit and rollback methods, but it > > lacks a begin method. > > > > Not considering the implementation of an autocommit feature, does this > > mean that the DB-API module must implicitely start, and possibly roll > > back transactions at certain points? > > > > I guess a cursor.execute must start a new transaction, where else must a > > transaction be started? Could anybody please clarify this? > > if the db support transactions a new transaction is started: > > 1. after .connect(), any moment just before the first .execute() > 2. after .commit() or .rollback(), any time before next .execute() Thanks, that's also what pyPgSQL currently seems to implement. I just weren't sure why it was done this way. Now I can try to implement transactions the right way in PySQLite. Thanks, Gerhard -- mail: gerhard bigfoot de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id AD24C930 public key fingerprint: 3FCC 8700 3012 0A9E B0C9 3667 814B 9CAA AD24 C930 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b'))) From mal@lemburg.com Mon May 27 11:09:26 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon, 27 May 2002 12:09:26 +0200 Subject: [DB-SIG] Transaction start References: <20020525041731.GA3983@lilith.my-fqdn.de> Message-ID: <3CF205D6.80905@lemburg.com> Gerhard H=E4ring wrote: > The DB-API Connection object has commit and rollback methods, but it > lacks a begin method. >=20 > Not considering the implementation of an autocommit feature, does this > mean that the DB-API module must implicitely start, and possibly roll > back transactions at certain points? >=20 > I guess a cursor.execute must start a new transaction, where else must = a > transaction be started? Could anybody please clarify this? Transactions, if supported, start implicitly at cursor creation time and after each call to .commit() or .rollback(). They can span multiple calls to .execute(). --=20 Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From daniel.dittmar@sap.com Mon May 27 12:20:08 2002 From: daniel.dittmar@sap.com (Dittmar, Daniel) Date: Mon, 27 May 2002 13:20:08 +0200 Subject: [DB-SIG] Transaction start Message-ID: > Transactions, if supported, start implicitly at cursor creation time > and after each call to .commit() or .rollback(). They can span > multiple calls to .execute(). Shouldn't that be 'session creation time'? I guess there are/could be implementations, where the transaction is started with the creation of the first cursor. But creating a second cursor will not start a new transaction. Daniel -- Daniel Dittmar SAP DB, SAP Labs Berlin daniel.dittmar@sap.com http://www.sapdb.org/ From fog@initd.org Mon May 27 12:54:39 2002 From: fog@initd.org (Federico Di Gregorio) Date: 27 May 2002 13:54:39 +0200 Subject: [DB-SIG] Transaction start In-Reply-To: References: Message-ID: <1022500480.1242.3.camel@nenya> --=-Ub6h7maiI2E4UI7M5+Am Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Il lun, 2002-05-27 alle 13:20, Dittmar, Daniel ha scritto: > > Transactions, if supported, start implicitly at cursor creation time > > and after each call to .commit() or .rollback(). They can span > > multiple calls to .execute(). >=20 > Shouldn't that be 'session creation time'? >=20 > I guess there are/could be implementations, where the transaction is star= ted > with the creation of the first cursor. But creating a second cursor will = not > start a new transaction. it depends. for example, psycopg create a new session on the first .execute() because of postgres returning the transaction creation time as 'now'. this was a problem for some users executing a .commit() and then a select say... 5h later and finding that 'now' was still 5h in the past. --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org Lasciate che i furetti vengano a me. -- Maria Luisa Benedetta Panzani --=-Ub6h7maiI2E4UI7M5+Am Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA88h5/vcCgrgZGjesRAgAvAJ9z1pGzV3PJ7nTjTKuFXClGKSRUoACgwWFd ZLTI4XCD4wy1DfRBLRBKS6I= =oV3z -----END PGP SIGNATURE----- --=-Ub6h7maiI2E4UI7M5+Am-- From haering_postgresql@gmx.de Tue May 28 20:36:47 2002 From: haering_postgresql@gmx.de (Gerhard =?iso-8859-15?Q?H=E4ring?=) Date: Tue, 28 May 2002 21:36:47 +0200 Subject: [DB-SIG] Multiple Statements Message-ID: <20020528193647.GA902@lilith.my-fqdn.de> >From my interpretation of the DB-API specfication, it's not possible to put multiple SELECT statements into one execute() call. That's what .executemany() with .nextset() is for, right? Do I really have to support this in a DB-API compliant module, though? What about multiple non-SELECT SQL statements seperated by ; in an execute() call (read: INSERT, UPDATE, PRAGMA). Would this be valid? Again I personally would use executemany(). I'm just wondering if I have to have to account for it in an execute() call. Gerhard -- mail: gerhard bigfoot de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id AD24C930 public key fingerprint: 3FCC 8700 3012 0A9E B0C9 3667 814B 9CAA AD24 C930 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b'))) From fog@initd.org Tue May 28 22:44:08 2002 From: fog@initd.org (Federico Di Gregorio) Date: 28 May 2002 23:44:08 +0200 Subject: [DB-SIG] Multiple Statements In-Reply-To: <20020528193647.GA902@lilith.my-fqdn.de> References: <20020528193647.GA902@lilith.my-fqdn.de> Message-ID: <1022622248.969.3.camel@nenya> --=-MnLJIhQ3DNmK3RwomwJe Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Il mar, 2002-05-28 alle 21:36, Gerhard H=E4ring ha scritto: > >From my interpretation of the DB-API specfication, it's not possible to > put multiple SELECT statements into one execute() call. That's what > executemany() with .nextset() is for, right? Do I really have to > support this in a DB-API compliant module, though? no. .nextset() is _not_ for multiple select. at least that's what was decided after some discussion about 1y ago. > What about multiple non-SELECT SQL statements seperated by ; in an > execute() call (read: INSERT, UPDATE, PRAGMA). Would this be valid? > Again I personally would use executemany(). I'm just wondering if I have > to have to account for it in an execute() call. don't really know. psycopg will allow that and even to end the list with a select but i don't know about other adapters. --=20 Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact fog@debian.org INIT.D Developer fog@initd.org We are all dust, Saqi, so play the lute We are all wind, Saqi, so bring wine. -- Omar Khayam --=-MnLJIhQ3DNmK3RwomwJe Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA88/onvcCgrgZGjesRAsHKAKCylWvjBWkiHLgzu9vOaGO2LSOXkgCgyLCQ 96QRzciJGCrZpFruDruvFA4= =jnNl -----END PGP SIGNATURE----- --=-MnLJIhQ3DNmK3RwomwJe-- From andy@dustman.net Tue May 28 23:41:47 2002 From: andy@dustman.net (Andy Dustman) Date: 28 May 2002 18:41:47 -0400 Subject: [DB-SIG] Multiple Statements In-Reply-To: <20020528193647.GA902@lilith.my-fqdn.de> References: <20020528193647.GA902@lilith.my-fqdn.de> Message-ID: <1022625707.1602.19.camel@4.0.0.10.in-addr.arpa> On Tue, 2002-05-28 at 15:36, Gerhard H=E4ring wrote: > From my interpretation of the DB-API specfication, it's not possible to > put multiple SELECT statements into one execute() call. That's what > .executemany() with .nextset() is for, right? Do I really have to > support this in a DB-API compliant module, though? Nearly all DB-API modules I have seen require a single statement passed to either execute() or executemany(), i.e. no multiple statement queries. nextset() is for SELECTs which return multiple result sets; I've never seen this used. =20 > What about multiple non-SELECT SQL statements seperated by ; in an > execute() call (read: INSERT, UPDATE, PRAGMA). Would this be valid? > Again I personally would use executemany(). I'm just wondering if I have > to have to account for it in an execute() call. Also, the only thing I have ever seen executemany() used for is a multi-row INSERT. --=20 Andy Dustman PGP: 0x930B8AB6 @ .net http://dustman.net/andy "Cogito, ergo sum." -- Rene Descartes "I yam what I yam and that's all that I yam." -- Popeye From wtrenker@shaw.ca Wed May 29 00:20:10 2002 From: wtrenker@shaw.ca (William Trenker) Date: Tue, 28 May 2002 16:20:10 -0700 Subject: [DB-SIG] Multiple Statements In-Reply-To: <1022625707.1602.19.camel@4.0.0.10.in-addr.arpa> References: <20020528193647.GA902@lilith.my-fqdn.de> <20020528193647.GA902@lilith.my-fqdn.de> Message-ID: <5.1.1.2.0.20020528161118.029808f0@shawmail> --Boundary_(ID_ZbaJf3i0qvp2v+lbQdXdxA) Content-type: text/plain; x-avg-checked=avg-ok-4677EA0; charset=iso-8859-1; format=flowed Content-transfer-encoding: quoted-printable At 06:41 PM 5/28/02 -0400, Andy Dustman wrote: >Nearly all DB-API modules I have seen require a single statement passed to= =20 >either execute() or executemany(), i.e. no multiple statement queries.=20 >nextset() is for SELECTs which return multiple result sets; I've never=20 >seen this used. I am the culprit behind Gerhard H=E4ring's question that prompted the above= =20 reply. I have posted a question on zope-db@zope.org asking how Zope ends=20 up passing a multiple SQL statement query from a ZSQL Method to a Zope=20 Database Adapter. I am simply trying to make sure that the Python SQLite DB-API 2.0 module=20 that Garhard, myself, et al are developing will also be Zope=20 compliant. Or, more specially, I'm trying to determine the "proper" way to= =20 interface a Zope DA to a Python DB-API 2.0 module. Bill Trenker http://pysqlite.sourceforge.net/ ---------- "The commandments of the LORD are right, bringing joy to the heart. The=20 commands of the LORD are clear, giving insight to life . . . For this is=20 the love of God, that we keep His commandments. And His commandments are=20 not burdensome." (Psalm 19:8, 1John=20 5:3) torahteacher.com --Boundary_(ID_ZbaJf3i0qvp2v+lbQdXdxA) Content-type: text/plain; charset=us-ascii; x-avg=cert; x-avg-checked=avg-ok-4677EA0 Content-transfer-encoding: 7BIT Content-disposition: inline --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.363 / Virus Database: 201 - Release Date: 5/21/02 --Boundary_(ID_ZbaJf3i0qvp2v+lbQdXdxA)-- From mal@lemburg.com Wed May 29 08:22:44 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 29 May 2002 09:22:44 +0200 Subject: [DB-SIG] Multiple Statements References: <20020528193647.GA902@lilith.my-fqdn.de> <1022625707.1602.19.camel@4.0.0.10.in-addr.arpa> Message-ID: <3CF481C4.9050904@lemburg.com> Andy Dustman wrote: > On Tue, 2002-05-28 at 15:36, Gerhard H=E4ring wrote: >=20 >>From my interpretation of the DB-API specfication, it's not possible to >>put multiple SELECT statements into one execute() call. That's what >>.executemany() with .nextset() is for, right? Do I really have to >>support this in a DB-API compliant module, though? >=20 >=20 > Nearly all DB-API modules I have seen require a single statement passed > to either execute() or executemany(), i.e. no multiple statement > queries. nextset() is for SELECTs which return multiple result sets; > I've never seen this used. The usual place where you'd find .nextset() used is when calling stored pocedures which result in multiple result sets. Having multiple statements in a single .execute() is normally not allowed by the databases (unless maybe you are defining a stored procedure in which case the multiple statements are wrapped up in a single procedure defining statement). >>What about multiple non-SELECT SQL statements seperated by ; in an >>execute() call (read: INSERT, UPDATE, PRAGMA). Would this be valid? >>Again I personally would use executemany(). I'm just wondering if I hav= e >>to have to account for it in an execute() call. >=20 >=20 > Also, the only thing I have ever seen executemany() used for is a > multi-row INSERT. --=20 Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ Meet us at EuroPython 2002: http://www.europython.org/