From jae@coe.uga.edu Mon Nov 3 16:59:31 1997 From: jae@coe.uga.edu (John A Eikenberry) Date: Mon, 3 Nov 1997 11:59:31 -0500 (EST) Subject: [DB-SIG] Examples? Message-ID: Hello all, I am just starting my first database applications. I am using mySQL and was planning on using the API as developed by this sig. I am having trouble getting started due to my lack of experience with databases and the lack of documentation. I have the API specification, but to a database newbie such as myself, it doesn't help that much. What I'd really like to see would be a few good examples. So... if anyone with some code they wouldn't mind sharing would pass it along, I'd really appreciate it. Related to this, I think it would be nice for db newbies such as myself if there were a collection of examples on the ftp site. So, if there is a good response to this querry, perhaps the results could be collected and placed there. Thanks, John Eikenberry [jae@ai.uga.edu - http://www.ai.uga.edu/students/jae/] ______________________________________________________________ "A society that will trade a little liberty for a little order will deserve neither and lose both." --B. Franklin _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Tue Nov 18 12:34:51 1997 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Tue, 18 Nov 1997 13:34:51 +0100 Subject: [DB-SIG] ANN: mxODBC (ODBC DB-API support for Adabas) Message-ID: <34718B6B.E2F82F9@uni-duesseldorf.de> This is the first release of a module I've written last week to finally have a reliable interface to my SQL database ADABAS D. It uses the ODBC interface to that DB, so should in general also work with other ODBC 2.0 compliant DBs. I tried to be as much DB-API 1.0 compatible as possible -- some small parts are missing though and the need for a dbi module is completely eliminated. See http://starship.skyport.net/~lemburg/mxODBC.html for more information and the ZIP-archive. I have tested it on Linux running Adabas 6.1.1. Linux Edition and Python1.5a4. Feedback is most welcome, bug reports too -- the main reason I post it here, since I want to use this module in production, but don't have the time to test every possible setup (that's what the bazar method is for, right ?!). -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From pa@tekla.fi Tue Nov 18 13:38:41 1997 From: pa@tekla.fi (Harri Pasanen) Date: Tue, 18 Nov 1997 15:38:41 +0200 Subject: [DB-SIG] ANN: mxODBC (ODBC DB-API support for Adabas) In-Reply-To: <34718B6B.E2F82F9@uni-duesseldorf.de> References: <34718B6B.E2F82F9@uni-duesseldorf.de> Message-ID: <9711181338.AA09983@tahma.tekla.fi> M.-A. Lemburg writes: > This is the first release of a module I've written last week > to finally have a reliable interface to my SQL database ADABAS D. > It uses the ODBC interface to that DB, so should in general > also work with other ODBC 2.0 compliant DBs. I tried to be as > much DB-API 1.0 compatible as possible -- some small parts > are missing though and the need for a dbi module is completely > eliminated. > > See http://starship.skyport.net/~lemburg/mxODBC.html for > more information and the ZIP-archive. I have tested it on Linux > running Adabas 6.1.1. Linux Edition and Python1.5a4. > Hmm.. looks like there has been duplicate work here: From: Michael Lausch Subject: [Announce] Solid and Adabas D Database Module released Newsgroups: comp.lang.python Date: 17 Nov 1997 01:56:57 +0100 Organization: g.a.m.s. Sender: mla@loki.gams.co.at Message-ID: NNTP-Posting-Host: 193.46.232.130 I just released the SolidPython-0.0.7 package which now includes an Adabas-D interface. You may find the tar.gz file on our FTP server: I'm currently adapting the interface to the newer Database API and plan to integrate the two modules into one, so that a generic ODBC API for Unix systems is available. This also means to implement an ODBC Manager. Sorry for the very long delay between the releases. I hope I can manage to be more responsive to bug fixes and feature wishes in the future. ------------------------------- Just for your information, Harri _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Tue Nov 18 14:16:01 1997 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Tue, 18 Nov 1997 15:16:01 +0100 Subject: [DB-SIG] ANN: mxODBC (ODBC DB-API support for Adabas) References: <34718B6B.E2F82F9@uni-duesseldorf.de> <9711181338.AA09983@tahma.tekla.fi> Message-ID: <3471A321.6F0BF805@uni-duesseldorf.de> Harri Pasanen wrote: > > M.-A. Lemburg writes: > > This is the first release of a module I've written last week > > to finally have a reliable interface to my SQL database ADABAS D. [...] > > Hmm.. looks like there has been duplicate work here: > > From: Michael Lausch > Subject: [Announce] Solid and Adabas D Database Module released [...] Yep, he released the new version the same day I finished my interface. I had tried his 0.0.6 version against Adabas, but it kept dumping core. Haven't looked into 0.0.7 yet. I was interested in how ODBC works... after 3 days hacking I now have a nice little new tool, much more experience with ODBC, refined macros and extension coding style, plus I found a bug in Adabas, that would have led me to look into the C code details sooner or later anyway. -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From pa@tekla.fi Tue Nov 18 19:55:12 1997 From: pa@tekla.fi (Harri Pasanen) Date: Tue, 18 Nov 1997 21:55:12 +0200 Subject: [DB-SIG] ANN: mxODBC (ODBC DB-API support for Adabas) References: <34718B6B.E2F82F9@uni-duesseldorf.de> <9711181338.AA09983@tahma.tekla.fi> <3471A321.6F0BF805@uni-duesseldorf.de> Message-ID: <3471F2A0.25F1FF20@tekla.fi> M.-A. Lemburg wrote: > > I was interested in how ODBC works... after 3 days hacking > I now have a nice little new tool, much more experience with > ODBC, refined macros and extension coding style, plus I found > a bug in Adabas, that would have led me to look into the C code > details sooner or later anyway. > True, duplicate work is seldom useless work in this industry, you seldom have to repeat yourself but instead keep learning new things. ;-) Harri _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From white@fnal.gov Fri Nov 21 06:26:07 1997 From: white@fnal.gov (Victoria White) Date: Fri, 21 Nov 1997 00:26:07 -0600 Subject: [DB-SIG] Insert for Oracledb Message-ID: <3475297F.2D9816F@fnal.gov> Please can someone send me a working code sample of how they successfully used the oracledb module (from Digital Creations) to insert one or more rows into an oracle database, preferably based on a List of previously constructed Tuples. I have looked at the example posted by Andrew Kuchling (for Solid), and read most of the past email, including a discussion about binding of variables using the :N notation. However, although I can query the database I have had no success at inserting rows, except by hardcoding the values into the sql string. Whatever I try I seem to get Parse errors, or too many arguments, or sql not properly terminated, or missing parens, or something! - even for 1 row. There seems to be very little activity on this SIG, with no updates to database API documentation since 1996! Is there really no-one out there using this stuff, for Oracle? Would appreciate help Vicky White _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From CYBERBUSINESS@juno.com Fri Nov 21 06:37:02 1997 From: CYBERBUSINESS@juno.com (A FRIEND) Date: Fri, 21 Nov 1997 01:37:02 -0500 Subject: No subject Message-ID: <19943672.886214@relay.comanche.denmark.eu> Thursday, November 20th, 1997 Authenticated sender is Subject: CHECK THIS OUT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello my name is Charles and i pardon the intrusion , But i just= think it is so cool how this program not only made me money ,= But the 4 reports taught me how to bulk email. I procrastinated= for a long time thinking it would never work , But after i did= it I found out that the informaton in the REports themselves was worth $20.00 and you can resale them that is great.i learned= so much about the internet and bulk emailing that i didnt know,= so if you are curious about the internet this is a good program= but the decision is up to you i am glad i did it Subj:=09 >>> $36,000 IN 14 WEEKS <<< Date:=0997-11-15 02:58:57 EST From:=0908339455@aol.com To:=09Friend@public.com I Never Thought I'd Be the One Telling You This: I Actually Read a Piece of E-Mail & I'm Going to Europe on the= Proceeds! Hello! My name is Karen Liddell; I'm a 35-year-old mom, wife, and= part-time accountant. As a rule, I delete all unsolicited= "junk" e-mail and use my account primarily for business. I= received what I assumed was this same e-mail countless times and= deleted it each time. About two months ago I received it again and, because of the= catchy subject line, I finally read it. Afterwards, I thought= , "OK, I give in, I'm going to try this. I can certainly afford= to invest $20 and, on the other hand, there's nothing wrong with= creating a little excess cash." I promptly mailed four $5 bills= and, after receiving the reports, paid a friend of mine a small= fee to send out some e-mail advertisements for me. After= reading the reports, I also learned how easy it is to bulk= e-mail for free! I was not prepared for the results. Everyday for the last six= weeks, my P.O. box has been overflowing with $5 bills; many days= the excess fills up an extra mail bin and I've had to upgrade to= the corporate-size box! I am stunned by all the money that= keeps rolling in! My husband and I have been saving for several years to make a= substantial downpayment on a house. Now, not only are we= purchasing a house with 40% down, we're going to Venice, Italy= to celebrate! I promise you, if you follow the directions in this e-mail and be= prepared to eventually set aside about an hour each day to= follow up (and count your money!), you will make at least as= much money as we did. You don't need to be a wiz at the= computer, but I'll bet you already are. If you can open an= envelope, remove the money, and send an e-mail message, then= you're on your way to the bank. Take the time to read this so= you'll understand how easy it is. If I can do this, so can= you! GO FOR IT NOW!! Karen Liddell The following is a copy of the e-mail I read: $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$= This is a LEGAL, MONEY-MAKING PHENOMENON. PRINT this letter, read the directions, THEN READ IT AGAIN !!! You are about to embark on the most profitable and unique program= you may ever see. Many times over, it has demonstrated and= proven its ability to generate large amounts of cash. This= program is showing fantastic appeal with a huge and ever-growing= on-line population desirous of additional income. This is a legitimate, LEGAL, money-making opportunity. It does= not require you to come in contact with people, do any hard= work, and best of all, you never have to leave the house, except= to get the mail and go to the bank! This truly is that lucky break you've been waiting for! Simply= follow the easy instructions in this letter, and your financial= dreams will come true! When followed correctly, this electronic,= multi-level marketing program works perfectly...100% EVERY= TIME! Thousands of people have used this program to: - Raise capital to start their own business - Pay off debts - Buy homes, cars, etc., - Even retire! This is your chance, so don't pass it up! -----------------------------------------------------------------= ----------------- OVERVIEW OF THIS EXTRAORDINARY ELECTRONIC MULTI-LEVEL MARKETING PROGRAM -----------------------------------------------------------------= ----------------- Basically, this is what we do: We send thousands of people a product for $5.00 that costs next= to nothing to produce and e-mail. As with all multi-level= businesses, we build our business by recruiting new partners and= selling our products. Every state in the U.S. allows you to= recruit new multi- level business online (via your computer). The products in this program are a series of four business and= financial reports costing $5.00 each. Each order you receive= via "snail mail" will include: * $5.00 cash * The name and number of the report they are ordering * The e-mail address where you will e-mail them the report they= ordered. To fill each order, you simply e-mail the product to the buyer. = THAT'S IT! The $5.00 is yours! This is the EASIEST electronic= multi-level marketing business anywhere! FOLLOW THE INSTRUCTIONS TO THE LETTER AND BE PREPARED TO REAP THE STAGGERING BENEFITS! ******* I N S T R U C T I O N S ******* This is what you MUST do: 1. Order all 4 reports shown on the list below (you can't sell= them if you don't order them). * For each report, send $5.00 CASH, the NAME & NUMBER OF= THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR RETURN POSTAL ADDRESS (in case of a problem) to the= person whose name appears on the list next to the report. * When you place your order, make sure you order each of= the four reports. You will need all four reports so that you can= save them on your computer and resell them. * Within a few days you will receive, via e-mail, each of= the four reports. Save them on your computer so they will be accessible= for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT-- DO NOT alter the names of the people who are= listed next to each report, or their sequence on the list, in any way= other than is instructed below in steps "a" through "d" or you will lose= out on the majority of your profits. Once you understand the way this= works, you'll also see how it doesn't work if you change it. Remember,= this method has been tested, and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the four reports, replace the name= and address under REPORT #1 with your name and address, moving the= one that was there down to REPORT #2. c. Move the name and address that was under REPORT #2 down= to REPORT #3. d. Move the name and address that was under REPORT #3 down= to REPORT #4. e. The name and address that was under REPORT #4 is removed= from the list and has NO DOUBT collected their 50 grand. Please make sure you copy everyone's name and address= ACCURATELY!!! 3. Take this entire letter, including the modified list of= names, and save it to your computer. Make NO changes to the instruction= portion of this letter. 4. Now you're ready to start an advertising campaign on the WORLDWIDE WEB! Advertising on the WEB is very, very= inexpensive, and there are HUNDREDS of FREE places to advertise. Another avenue which you could use for advertising is e-mail lists. You can buy these lists for under $20/2,000 addresses or= you can pay someone a minimal charge to take care of it for= you. BE SURE TO START YOUR AD CAMPAIGN IMMEDIATELY! 5. For every $5.00 you receive, all you must do is e-mail them= the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY= send out, with YOUR name and address on it, will be prompt because= they can't advertise until they receive the report! ------------------------------------------ AVAILABLE REPORTS ------------------------------------------ ***Order Each REPORT by NUMBER and NAME*** Notes: - ALWAYS SEND $5 CASH FOR EACH REPORT - ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL - Make sure the cash is concealed by wrapping it in at least two= sheets of paper - On one of those sheets of paper, include: (a) the number &= name of the report you are ordering, (b) your e-mail address,= and (c) your postal address. _________________________________________________________________= REPORT #1 "HOW TO MAKE $250,000 THROUGH MULTI-LEVEL SALES" ORDER REPORT #1 FROM: MGL Enterprises 8100 W. Crestline Ave. A-15 Box 120 Littleton, CO 80123-1200 _________________________________________________________________= REPORT #2 "MAJOR CORPORATIONS AND MULTI-LEVEL SALES" ORDER REPORT #2 FROM: RD Rhodes p.o box 53372 Indpls,in 46253-3372 _________________________________________________________________= REPORT #3 "SOURCES FOR THE BEST MAILING LISTS" ORDER REPORT #3 FROM: N. B. Bostrom 3871 HWY 527 HAUGHTON, LA 71037 _________________________________________________________________= REPORT #4 "EVALUATING MULTI-LEVEL SALES PLANS" ORDER REPORT #4 FROM: BUSSINESS SERVICES UNLIMITED P.O BOX 241075 INDPLS,IN 46224-1075 _________________________________________________________________= -----------------------------------------------------------------= --------------------------------- HERE'S HOW THIS AMAZING PLAN WILL MAKE YOU $MONEY$ -----------------------------------------------------------------= --------------------------------- Let's say you decide to start small just to see how well it= works. Assume your goal is to get 10 people to participate on= your first level. (Placing a lot of FREE ads on the internet= will EASILY get a larger response.) Also assume that everyone= else in YOUR ORGANIZATION gets ONLY 10 downline members. Follow= this example to achieve the STAGGERING results below. 1st level--your 10 members with= $5...........................................$50 2nd level--10 members from those 10 ($5 x= 100)..................$500 3rd level--10 members from those 100 ($5 x= 1,000)..........$5,000 4th level--10 members from those 1,000 ($5 x 10,000)...$50,000 THIS TOTALS = ----------->$55,550 Remember friends, this assumes that the people who participate= only recruit 10 people each. Think for a moment what would= happen if they got 20 people to participate! Most people get= 100's of participants! THINK ABOUT IT! Your cost to participate in this is practically nothing (surely= you can afford $20). You obviously already have an internet= connection and e-mail is FREE!!! REPORT#3 shows you the most= productive methods for bulk e-mailing and purchasing e-mail= lists. Some list & bulk e-mail vendors even work on trade! About 50,000 new people get online every month! *******TIPS FOR SUCCESS******* * TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and= follow the directions accurately. * Send for the four reports IMMEDIATELY so you will have them= when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report to comply with the U.S. Postal & Lottery Laws,= Title 18,Sections 1302 and 1341 or Title 18, Section 3005 in the= U.S. Code, also Code of Federal Regs. vol. 16, Sections 255 and 436,= which state that "a product or service must be exchanged for money= received." * ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. * Be patient and persistent with this program. If you follow= the instructions exactly, the results WILL undoubtedly be= SUCCESSFUL! * ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! *******YOUR SUCCESS GUIDELINE******* Follow these guidelines to guarantee your success: If you don't receive 10 to 20 orders for REPORT #1 within two= weeks, continue advertising until you do. Then, a couple of= weeks later you should receive at least 100 orders for REPORT= #2. If you don't, continue advertising until you do. Once you= have received 100 or more orders for REPORT #2, YOU CAN RELAX,= because the system is already working for you, and the cash will= continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in= front of a DIFFERENT report. You can KEEP TRACK of your= PROGRESS by watching which report people are ordering from you. = If you want to generate more income, send another batch of= e-mails and start the whole process again! There is no limit to= the income you will generate from this business! NOTE: If you need help with starting a business, registering a= business name, how income tax is handled, etc.,= contact your local office of the Small Business Administration= (a Federal agency) for free help and answers to questions. Also,= the Internal Revenue Service offers free help via telephone and= free seminars about business taxes. *******T E S T I M O N I A L S******* This program does work, but you must follow it EXACTLY! = Especially the rule of not trying to place your name in a= different position, it won't work and you'll lose a lot of= potential income. I'm living proof that it works. It really is= a great opportunity to make relatively easy money, with little= cost to you. If you do choose to participate, follow the= program exactly, and you'll be on your way to financial= security. Sean McLaughlin, Jackson, MS My name is Frank. My wife, Doris, and I live in Bel-Air, MD.= I am a cost accountant with a major U.S. Corporation and I make= pretty good money. When I received the program I grumbled to= Doris about receiving "junk mail." I made fun of the whole= thing, spouting my knowledge of the population and percentages= involved. I "knew" it wouldn't work. Doris totally ignored my= supposed intelligence and jumped in with both feet. I made= merciless fun of her, and was ready to lay the old "I told you= so" on her when the thing didn't work... well, the laugh was on= me! Within two weeks she had received over 50 responses. Within= 45 days she had received over $147,200 in $5 bills! I was= shocked! I was sure that I had it all figured and that it= wouldn't work. I AM a believer now. I have joined Doris in her= "hobby." I did have seven more years until retirement, but I= think of the "rat race" and it's not for me. We owe it all to= MLM. Frank T., Bel-Air, MD I just want to pass along my best wishes and encouragement to= you. Any doubts you have will vanish when your first orders= come in. I even checked with the U.S. Post Office to verify that= the plan was legal. It definitely is! IT WORKS!!! Paul Johnson, Raleigh, NC The main reason for this letter is to convince you that this= system is honest, lawful, extremely profitable, and is a way to= get a large amount of money in a short time. I was approached= several times before I checked this out. I joined just to see= what one could expect in return for the minimal effort and money= required. To my astonishment, I received $36,470.00 in the= first 14 weeks, with money still coming in. Sincerely yours, Phillip A. Brown, Esq. Not being the gambling type, it took me several weeks to make= up my mind to participate in this plan. But conservative that I= am, I decided that the initial investment was so little that= there was just no way that I wouldn't get enough orders to at= least get my money back. Boy, was I surprised when I found my= medium-size post office box crammed with orders! For awhile, it= got so overloaded that I had to start picking up my mail at the= window. I'll make more money this year than any 10 years of my= life before. The nice thing about this deal is that it doesn't= matter where in the U.S. the people live. There simply isn't a= better investment with a faster return. Mary Rockland, Lansing, MI I had received this program before. I deleted it, but later I= wondered if I shouldn't have given it a try. Of course, I had no= idea who to contact to get another copy, so I had to wait until= I was e-mailed another program...11 months passed then it= came...I didn't delete this one!...I made more than $41,000 on= the first try!! D. Wilburn, Muncie, IN This is my third time to participate in this plan. We have= quit our jobs, and will soon buy a home on the beach and live= off the interest on our money. The only way on earth that this= plan will work for you is if you do it. For your sake, and for= your family's sake don't pass up this golden opportunity. Good= luck and happy spending! Charles Fairchild, Spokane, WA ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM!!! _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From caryc@shore.net Fri Nov 21 13:44:11 1997 From: caryc@shore.net (Cary Collett) Date: Fri, 21 Nov 1997 08:44:11 -0500 (EST) Subject: [DB-SIG] Insert for Oracledb In-Reply-To: <3475297F.2D9816F@fnal.gov> from "Victoria White" at Nov 21, 97 00:26:07 am Message-ID: <199711211344.IAA06409@shell2.shore.net> Vicky, Here's a quick, dirty example... >>> import oracledb >>> cobj = oracledb.oracledb('foo/bar') >>> cu = cobj.cursor() >>> a = (1,11714,10,0,'Bob') >>> qs = "INSERT INTO ppiOrder (orderID,accountID,amount,discountPercent,salesRepName) VALUES (" + str(a[0]) + "," + str(a[1]) + "," + str(a[2]) + "," + str(a[3]) + ",'" + a[4] + "')" >>> qs "INSERT INTO ppiOrder (orderID,accountID,amount,discountPercent,salesRepName) VALUES (1,11714,10,0,'Bob')" >>> cu.execute(qs) 1 >>> cobj.rollback() You might also have your program send the query string to the stdout or stderr to see what it looks like. Try it in sqlplus, it will give you a little bit better error diagnostics. Hope this helps, Cary > > Please can someone send me a working code sample of how they > successfully used the oracledb module (from Digital Creations) to insert > one or more rows into an oracle database, preferably based on a List of > previously constructed Tuples. > I have looked at the example posted by Andrew Kuchling (for Solid), and > read most of the past email, including a discussion about binding of > variables using the :N notation. However, although I can query the > database I have had no success at inserting rows, except by hardcoding > the values into the sql string. > Whatever I try I seem to get Parse errors, or too many arguments, or > sql not properly terminated, or missing parens, or something! - even > for 1 row. > There seems to be very little activity on this SIG, with no updates to > database API documentation since 1996! Is there really no-one out > there using this stuff, for Oracle? > Would appreciate help > Vicky White > > > _______________ > DB-SIG - SIG on Tabular Databases in Python > > send messages to: db-sig@python.org > administrivia to: db-sig-request@python.org > _______________ > _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From white@fnal.gov Fri Nov 21 14:37:26 1997 From: white@fnal.gov (Victoria White) Date: Fri, 21 Nov 1997 08:37:26 -0600 Subject: [DB-SIG] Insert for Oracledb References: <199711211344.IAA06409@shell2.shore.net> Message-ID: <34759CA6.C8BAAFAE@fnal.gov> Cary, Yes, thank you for your response. That indeed does work, however I put that into the category of 'hardcoding the values into the sql string' - since you basically explicitly convert to ASCII with str() and insert into the sql string. I had hoped that I could use execute(sqlstring, [params...]) as documented in the DBI document with params presented as one (or more) parameters giving basically a List of Tuples (or arrays of values) to be "bound" to the input column names given, in some Oracle-specific/binding magic format, in the sql string. However, I find that a) only one param is permitted with the oracledb implementation and b) I cannot find the secret way to "bind" the List of Tuples into the sql command - not even for a single record insert, although I really want it to work for a whole list of tuples. It is probably extremely simple and just that I don't understand the notation involved in specifying the sqlstring and its column names to be bound. However, I do appreciate your response and am interested to find another living soul using this package. Vicky Cary Collett wrote: > Vicky, > > Here's a quick, dirty example... > > >>> import oracledb > >>> cobj = oracledb.oracledb('foo/bar') > >>> cu = cobj.cursor() > >>> a = (1,11714,10,0,'Bob') > >>> qs = "INSERT INTO ppiOrder (orderID,accountID,amount,discountPercent,salesRepName) VALUES (" + str(a[0]) + "," + str(a[1]) + "," + str(a[2]) + "," + str(a[3]) + ",'" + a[4] + "')" > >>> qs > "INSERT INTO ppiOrder (orderID,accountID,amount,discountPercent,salesRepName) VALUES (1,11714,10,0,'Bob')" > >>> cu.execute(qs) > 1 > >>> cobj.rollback() > > You might also have your program send the query string to the stdout > or stderr to see what it looks like. Try it in sqlplus, it will > give you a little bit better error diagnostics. > > Hope this helps, > > Cary > > > > > Please can someone send me a working code sample of how they > > successfully used the oracledb module (from Digital Creations) to insert > > one or more rows into an oracle database, preferably based on a List of > > previously constructed Tuples. > > I have looked at the example posted by Andrew Kuchling (for Solid), and > > read most of the past email, including a discussion about binding of > > variables using the :N notation. However, although I can query the > > database I have had no success at inserting rows, except by hardcoding > > the values into the sql string. > > Whatever I try I seem to get Parse errors, or too many arguments, or > > sql not properly terminated, or missing parens, or something! - even > > for 1 row. > > There seems to be very little activity on this SIG, with no updates to > > database API documentation since 1996! Is there really no-one out > > there using this stuff, for Oracle? > > Would appreciate help > > Vicky White > > > > > > _______________ > > DB-SIG - SIG on Tabular Databases in Python > > > > send messages to: db-sig@python.org > > administrivia to: db-sig-request@python.org > > _______________ > > _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From hiren@lexis-nexis.com Fri Nov 21 15:15:49 1997 From: hiren@lexis-nexis.com (Hiren Hindoccha) Date: Fri, 21 Nov 1997 10:15:49 -0500 (EST) Subject: [DB-SIG] Insert for Oracledb In-Reply-To: <3475297F.2D9816F@fnal.gov> Message-ID: On Fri, 21 Nov 1997, Victoria White wrote: > Please can someone send me a working code sample of how they > successfully used the oracledb module (from Digital Creations) to insert Wouldn't the following work - stmt = """ INSERT INTO people VALUES ('%s','%s','%s','%s','%s','%s','%s','%s',%s); """ sqlstmt = stmt % (your_tuple) cur.executesql(sqlstmt) I've used the above to do the inserts. Is the problem that you don't want to specify the data types that should be inserted into the table ? Hiren -------------------------------------------------------- "!sgub evah t'nseod CP sihT ?sgub naem ayaddahW" _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From mlorton@microsoft.com Fri Nov 21 16:30:07 1997 From: mlorton@microsoft.com (Michael Lorton) Date: Fri, 21 Nov 1997 08:30:07 -0800 Subject: [DB-SIG] Insert for Oracledb Message-ID: <0845FCDE78BFD011A17600805FD43A8F0108F54E@red-45-msg.dns.microsoft.com> The Right Way: >>> qs = "INSERT INTO ppiOrder (orderID,accountID,amount,discountPercent,salesRepName) VALUES (:1, :2, :3, :4)" >>> cu.execute(qs, a) If you want to experiment with the way Cary and others suggested (i.e., physically pasting the text into the query), consider inserting a work with a single quote ("It won't work" :-) M. > -----Original Message----- > From: Cary Collett [SMTP:caryc@shore.net] > Sent: Friday, November 21, 1997 5:44 AM > To: white@fnal.gov > Cc: db-sig@python.org > Subject: Re: [DB-SIG] Insert for Oracledb > > > Vicky, > > Here's a quick, dirty example... > > >>> import oracledb > >>> cobj = oracledb.oracledb('foo/bar') > >>> cu = cobj.cursor() > >>> a = (1,11714,10,0,'Bob') > >>> qs = "INSERT INTO ppiOrder > (orderID,accountID,amount,discountPercent,salesRepName) VALUES (" + > str(a[0]) + "," + str(a[1]) + "," + str(a[2]) + "," + str(a[3]) + ",'" + > a[4] + "')" > >>> qs > "INSERT INTO ppiOrder > (orderID,accountID,amount,discountPercent,salesRepName) VALUES > (1,11714,10,0,'Bob')" > >>> cu.execute(qs) > 1 > >>> cobj.rollback() > > > You might also have your program send the query string to the stdout > or stderr to see what it looks like. Try it in sqlplus, it will > give you a little bit better error diagnostics. > > > > Hope this helps, > > Cary > > > > > Please can someone send me a working code sample of how they > > successfully used the oracledb module (from Digital Creations) to insert > > one or more rows into an oracle database, preferably based on a List of > > previously constructed Tuples. > > I have looked at the example posted by Andrew Kuchling (for Solid), and > > read most of the past email, including a discussion about binding of > > variables using the :N notation. However, although I can query the > > database I have had no success at inserting rows, except by hardcoding > > the values into the sql string. > > Whatever I try I seem to get Parse errors, or too many arguments, or > > sql not properly terminated, or missing parens, or something! - even > > for 1 row. > > There seems to be very little activity on this SIG, with no updates to > > database API documentation since 1996! Is there really no-one out > > there using this stuff, for Oracle? > > Would appreciate help > > Vicky White > > > > > > _______________ > > DB-SIG - SIG on Tabular Databases in Python > > > > send messages to: db-sig@python.org > > administrivia to: db-sig-request@python.org > > _______________ > > > > > _______________ > DB-SIG - SIG on Tabular Databases in Python > > send messages to: db-sig@python.org > administrivia to: db-sig-request@python.org > _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From magnus.lycka@tripnet.se Sat Nov 22 14:30:18 1997 From: magnus.lycka@tripnet.se (Magnus Lycka) Date: Sat, 22 Nov 1997 15:30:18 +0100 Subject: [DB-SIG] Insert for Oracledb In-Reply-To: <34759CA6.C8BAAFAE@fnal.gov> References: <199711211344.IAA06409@shell2.shore.net> Message-ID: <3.0.1.32.19971122153018.007967b0@mail1.tripnet.se> At 08:37 1997-11-21 -0600, Victoria White wrote: > I had hoped that I could use execute(sqlstring, [params...]) as documented in >the DBI document with params presented as one (or more) parameters giving >basically a List of Tuples (or arrays of values) to be "bound" to the input >column names given, in some Oracle-specific/binding magic format, in the sql >string. However, I find that a) only one param is permitted with the oracledb >implementation and >b) I cannot find the secret way to "bind" the List of Tuples into the sql command >- not even for a single record insert, although I really want it to work for a >whole list of tuples. It is probably extremely simple and just that I don't >understand the notation involved in specifying the sqlstring and its column names >to be bound. However, I do appreciate your response and am interested to find >another living soul using this package. > Vicky If I understand correctly, you want to INSERT several records in one INSERT statement. As far as I understand you can't do that in SQL (Oracle or any other version I know of) unless you INSERT from a SELECT. I.e. you can write: INSERT INTO a_table (a_column) VALUES ('a_value'); or INSERT INTO a_table (a_column) SELECT the_column FROM the_table WHERE something; I don't think there is a way to INSERT several records at once, unless they come from a SELECT as in the second example below. If you have a list of records/tuples in your Python app, I think you will have to loop through them and make an INSERT for each one of them. I understand that you get the impression that you would be able to do multiple inserts from the DBI spec though. I honestly don't know what the list-of-tuples is for. Can anyone enlighten me about that? It would be nice if it looped through a supplied list if it recieved several tuples and performed the command for each of them, although it's not really something you need, and if you have several inserts of updates, you will probably want to check for error conditions after each one anyway (although that might not be a problem if exceptions are used in a proper way I guess). Magnus -- Magnus Lycka, S/W Engineer, M.Sc.E.E; Folktrov. 6C, 907 51 Umea, Sweden Tel: +46(0)90 198 498, GSM: +46(0)70 582 80 65, Fax: +46(0)70 612 80 65 _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Sat Nov 22 15:56:01 1997 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Sat, 22 Nov 1997 16:56:01 +0100 Subject: [DB-SIG] Insert for Oracledb References: <199711211344.IAA06409@shell2.shore.net> <3.0.1.32.19971122153018.007967b0@mail1.tripnet.se> Message-ID: <34770091.4BED791B@uni-duesseldorf.de> Magnus Lycka wrote: > I understand that you get the impression that you would be able to do > multiple inserts from the DBI spec though. I honestly don't know what > the list-of-tuples is for. Can anyone enlighten me about that? It would > be nice if it looped through a supplied list if it recieved several tuples > and performed the command for each of them, although it's not really something > you need, and if you have several inserts of updates, you will probably > want to > check for error conditions after each one anyway (although that might not be > a problem if exceptions are used in a proper way I guess). There seems to be a misunderstanding here: If you pass a list of tuples to the cursor.execute() method as parameter, then the command given will be executed for each tuple in the list. The implementation can do this either in one go, or a by calling the execute API for every item. -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From billtut@microsoft.com Sun Nov 23 01:13:13 1997 From: billtut@microsoft.com (Bill Tutt) Date: Sat, 22 Nov 1997 17:13:13 -0800 Subject: [DB-SIG] Insert for Oracledb Message-ID: <4D0A23B3F74DD111ACCD00805F31D8104536D8@red-msg-50.dns.microsoft.com> M-A is correct in that is the say things should happen, but oracledb-0.1.3 doesn't do that currently. Neither does the Win32 ODBC module either.. (All patches to fix the problem graciouslly excepted). Passing a tuple of tuples to an insert() should ONLY be used inside a transaction, because if you don't you won't know where in the # of rows to insert, the failure occurred.. Wether this is a good thing or bad thing depends on your situtation. Bill Tutt Not speaking for Microsoft, etc.. > -----Original Message----- > From: M.-A. Lemburg [SMTP:lemburg@uni-duesseldorf.de] > Sent: Saturday, November 22, 1997 7:56 AM > To: db > Subject: Re: [DB-SIG] Insert for Oracledb > > Magnus Lycka wrote: > > I understand that you get the impression that you would be able to do > > multiple inserts from the DBI spec though. I honestly don't know what > > the list-of-tuples is for. Can anyone enlighten me about that? It would > > be nice if it looped through a supplied list if it recieved several > tuples > > and performed the command for each of them, although it's not really > something > > you need, and if you have several inserts of updates, you will probably > > want to > > check for error conditions after each one anyway (although that might > not be > > a problem if exceptions are used in a proper way I guess). > > There seems to be a misunderstanding here: > > If you pass a list of tuples to the cursor.execute() method as > parameter, then the command given will be executed for each tuple > in the list. The implementation can do this either in one go, or > a by calling the execute API for every item. > > -- > Marc-Andre Lemburg > > > > _______________ > DB-SIG - SIG on Tabular Databases in Python > > send messages to: db-sig@python.org > administrivia to: db-sig-request@python.org > _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Sun Nov 23 13:12:15 1997 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Sun, 23 Nov 1997 14:12:15 +0100 Subject: [DB-SIG] Insert for Oracledb References: <4D0A23B3F74DD111ACCD00805F31D8104536D8@red-msg-50.dns.microsoft.com> <34782304.52FF4DBC@uni-duesseldorf.de> Message-ID: <34782BAF.3611365D@uni-duesseldorf.de> Bill Tutt wrote: > > M-A is correct in that is the say things should happen, but oracledb-0.1.3 > doesn't do that currently. > Neither does the Win32 ODBC module either.. (All patches to fix the problem > graciouslly excepted). They don't ? Sorry, I didn't know that (not using them so...). If Oracle has an ODBC interface lib, you could try the mxODBC-module, which does allow lists of tuples to be passed to .execute(). Also, for those who work on the Win32 ODBC module: you might be able to use some of the code in there... http://starship.skyport.net/~lemburg/mxODBC.html > Passing a tuple of tuples to an insert() should ONLY be used inside a > transaction, because if you don't > you won't know where in the # of rows to insert, the failure occurred.. > Wether this is a good thing or bad thing depends on your situtation. ODBC has an interface to return the row number where the error occurred. If the module does the executes one at a time the information is also available. What's missing in both cases is a standard of how to access the row number. Maybe the execute should return the number of rows successfully executed (it'll stop executing whenever an error occurs, so that number would in this case indicate the error position in the list). As I am new to the list: has there been discussion about what to do with the auto-commit feature in ODBC ? I've switched it off per default but made an interface available to turn it back on, since I find it rather useful in situations where concurrent access to the DB is important. -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From tismer@appliedbiometrics.com Sun Nov 23 22:18:00 1997 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Sun, 23 Nov 1997 23:18:00 +0100 Subject: [DB-SIG] Insert for Oracledb References: <4D0A23B3F74DD111ACCD00805F31D8104536D8@red-msg-50.dns.microsoft.com> <34782304.52FF4DBC@uni-duesseldorf.de> <34782BAF.3611365D@uni-duesseldorf.de> Message-ID: <3478AB98.3F0EFF41@appliedbiometrics.com> [ multiple inserts ] > They don't ? Sorry, I didn't know that (not using them so...). If > Oracle has an ODBC interface lib, you could try the mxODBC-module, which > does allow lists of tuples to be passed to .execute(). Also, for those > who work on the Win32 ODBC module: you might be able to use some > of the code in there... I'm working on the ODBC module. Right now I changed it to use the new Date type from pywintypes instead of dbiDate. This gives true dates to all my patient data. > http://starship.skyport.net/~lemburg/mxODBC.html Thanks, I'll give it a look. Anything urgent which must be done for the ODBC module? I'm going to post it, soon. cheers - pirx -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Alle 101 : *Starship* http://starship.skyport.net 10553 Berlin : PGP key -> http://pgpkeys.mit.edu we're tired of banana software - shipped green, ripens at home _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From jim@digicool.com Mon Nov 24 12:20:03 1997 From: jim@digicool.com (Jim Fulton) Date: Mon, 24 Nov 1997 07:20:03 -0500 Subject: [DB-SIG] Insert for Oracledb References: <4D0A23B3F74DD111ACCD00805F31D8104536D8@red-msg-50.dns.microsoft.com> <34782304.52FF4DBC@uni-duesseldorf.de> <34782BAF.3611365D@uni-duesseldorf.de> <3478AB98.3F0EFF41@appliedbiometrics.com> Message-ID: <347970F3.40C1@digicool.com> Christian Tismer wrote: > > I'm working on the ODBC module. Right now I changed it to use the > new Date type from pywintypes instead of dbiDate. This gives > true dates to all my patient data. Way cool! > Thanks, I'll give it a look. > Anything urgent which must be done for the ODBC module? I need an interface to SQLTables, so that I can discover tables in data sources. I'm in the process of SWIGing ODBC to accomplish this. Has anyone else SWIGed ODBC? If you want to add SQLTable support to the ODBC module, then I won't bother SWIGing ODBC, although it has been fun learning SWIG. :-) Jim _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Mon Nov 24 14:20:32 1997 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Mon, 24 Nov 1997 15:20:32 +0100 Subject: [DB-SIG] Insert for Oracledb References: <4D0A23B3F74DD111ACCD00805F31D8104536D8@red-msg-50.dns.microsoft.com> <34782304.52FF4DBC@uni-duesseldorf.de> <34782BAF.3611365D@uni-duesseldorf.de> <3478AB98.3F0EFF41@appliedbiometrics.com> <347970F3.40C1@digicool.com> Message-ID: <34798D30.4598216@uni-duesseldorf.de> Jim Fulton wrote: > > I need an interface to SQLTables, so that I can discover > tables in data sources. Shouldn't be much of a problem. Though it kind of bypasses the DB-API where all executes go through cursor.execute. The ODBC APIs SQLTable, SQLStatistics, etc. all do pretty much the same as an execute with a DB-specific table would (I guess the naming differences among the different DBs caused these APIs to appear). -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From tismer@appliedbiometrics.com Mon Nov 24 18:01:14 1997 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Mon, 24 Nov 1997 19:01:14 +0100 Subject: [DB-SIG] Insert for Oracledb References: <4D0A23B3F74DD111ACCD00805F31D8104536D8@red-msg-50.dns.microsoft.com> <34782304.52FF4DBC@uni-duesseldorf.de> <34782BAF.3611365D@uni-duesseldorf.de> <3478AB98.3F0EFF41@appliedbiometrics.com> <347970F3.40C1@digicool.com> <34798D30.4598216@uni-duesseldorf.de> Message-ID: <3479C0EA.1AC0FA2D@appliedbiometrics.com> M.-A. Lemburg wrote: > > Jim Fulton wrote: > > > > I need an interface to SQLTables, so that I can discover > > tables in data sources. > > Shouldn't be much of a problem. Though it kind of bypasses > the DB-API where all executes go through cursor.execute. > The ODBC APIs SQLTable, SQLStatistics, etc. all do pretty > much the same as an execute with a DB-specific table would > (I guess the naming differences among the different DBs > caused these APIs to appear). Both makes sense! SQLTables gives you the tables which your ODBC driver wants you to see. That's what you get when connecting through Access f.i. To have a general way is quite nice. But using the special vendor-specific metatables has some advantages which can't always be emulated. Example SAS: There is a virtual workspace "dictionary" which has very nice virtual entries like "tables, columns, views, workspaces" and all of that. This gives a very complete description of all the tables which are accessible, much more than SQLTables will give. And it all works through than nice simple standard peephole, with the easy little ODBC module we have. I'm a bit concerned about all these c modules necessary. I'd keep them to a minimum, to do the hard work. Everything else would be much easier to test and configure if it could go into Python code. Sam Rushing did something with his calldll module. This goes too far into the opposite direction. A set of kernel functions would be right to code in c. It should use less lines than DBI and ODBC and mxODBC, expose what's necessary for the structures, but allow for some sophisticated Python code to deal with special cases. If I had to adapt to another ODBC driver, I'd like to do it from Python, try it out with the pywin browser, all of that. Does it make sense to expose the ODBC API partially, provide a row of basic finctions and buld upon it from Python? cheers - pirx -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Alle 101 : *Starship* http://starship.skyport.net 10553 Berlin : PGP key -> http://pgpkeys.mit.edu we're tired of banana software - shipped green, ripens at home _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From aaron_watters@classic.msn.com Mon Nov 24 12:02:04 1997 From: aaron_watters@classic.msn.com (aaron watters) Date: Mon, 24 Nov 97 12:02:04 UT Subject: [DB-SIG] Insert for Oracledb Message-ID: The "list of tuples" for dynamic value substitution is an obvious implicit loop that allows inserts to run in a more optimized fashion. I don't think it's always (ever?) implemented, however. I'll implement it for Gadfly today. :) -- Aaron Watters ---------- From: owner-db-sig@python.org on behalf of Magnus Lycka Sent: Saturday, November 22, 1997 9:30 AM To: db Subject: Re: [DB-SIG] Insert for Oracledb At 08:37 1997-11-21 -0600, Victoria White wrote: > I had hoped that I could use execute(sqlstring, [params...]) as documented in >the DBI document with params presented as one (or more) parameters giving >basically a List of Tuples (or arrays of values) to be "bound" to the input >column names given, in some Oracle-specific/binding magic format, in the sql >string. However, I find that a) only one param is permitted with the oracledb >implementation and >b) I cannot find the secret way to "bind" the List of Tuples into the sql command >- not even for a single record insert, although I really want it to work for a >whole list of tuples. It is probably extremely simple and just that I don't >understand the notation involved in specifying the sqlstring and its column names >to be bound. However, I do appreciate your response and am interested to find >another living soul using this package. > Vicky If I understand correctly, you want to INSERT several records in one INSERT statement. As far as I understand you can't do that in SQL (Oracle or any other version I know of) unless you INSERT from a SELECT. I.e. you can write: INSERT INTO a_table (a_column) VALUES ('a_value'); or INSERT INTO a_table (a_column) SELECT the_column FROM the_table WHERE something; I don't think there is a way to INSERT several records at once, unless they come from a SELECT as in the second example below. If you have a list of records/tuples in your Python app, I think you will have to loop through them and make an INSERT for each one of them. I understand that you get the impression that you would be able to do multiple inserts from the DBI spec though. I honestly don't know what the list-of-tuples is for. Can anyone enlighten me about that? It would be nice if it looped through a supplied list if it recieved several tuples and performed the command for each of them, although it's not really something you need, and if you have several inserts of updates, you will probably want to check for error conditions after each one anyway (although that might not be a problem if exceptions are used in a proper way I guess). Magnus -- Magnus Lycka, S/W Engineer, M.Sc.E.E; Folktrov. 6C, 907 51 Umea, Sweden Tel: +46(0)90 198 498, GSM: +46(0)70 582 80 65, Fax: +46(0)70 612 80 65 _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Mon Nov 24 22:53:26 1997 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Mon, 24 Nov 1997 23:53:26 +0100 Subject: [DB-SIG] Insert for Oracledb References: <4D0A23B3F74DD111ACCD00805F31D8104536D8@red-msg-50.dns.microsoft.com> <34782304.52FF4DBC@uni-duesseldorf.de> <34782BAF.3611365D@uni-duesseldorf.de> <3478AB98.3F0EFF41@appliedbiometrics.com> <347970F3.40C1@digicool.com> <34798D30.4598216@uni-duesseldorf.de> <3479C0EA.1AC0FA2D@appliedbiometrics.com> Message-ID: <347A0566.2849D4E@uni-duesseldorf.de> Christian Tismer wrote: > > I'm a bit concerned about all these c modules necessary. I'd keep > them to a minimum, to do the hard work. Everything else would be > much easier to test and configure if it could go into Python code. There's a problem with this approach: you often need to allocate buffer > > Sam Rushing did something with his calldll module. This goes too > far into the opposite direction. A set of kernel functions would be > right to code in c. It should use less lines than DBI and ODBC and > mxODBC, expose what's necessary for the structures, but allow for > some sophisticated Python code to deal with special cases. > > If I had to adapt to another ODBC driver, I'd like to do it from > Python, try it out with the pywin browser, all of that. Ideally you would only have to poke around the ODBC interface a bit: not every "ODBC driver" does really conform to the standard. E.g. take the SQLTables() API: Adabas doesn't return any qualifier (it's always NULL) and does some rather nasty truncations too... those are things you can't change no matter whether you're using Python or C. You're always better off having a database abstraction layer in your apps. That can be done in Python and so is easy to adjust to new environments. > Does it make sense to expose the ODBC API partially, provide a row > of basic finctions and buld upon it from Python? Hmm, the DB API is already pretty lean. I guess you always need some 1500 lines of C code to get a reasonably working interface. I'm currently working on the catalog functions: SQLColumnPrivileges SQLColumns SQLForeignKeys SQLPrimaryKeys SQLProcedureColumns SQLProcedures SQLSpecialColumns SQLStatistics SQLTablePrivileges SQLTables Most of them will be in Version 0.3 of mxODBC. (I also fixed a bug that caused a segfault when reusing a cursor with a larger output column set than the first .execute.) Should be out by the end of the week. BTW: I'd really like to make it work under Win32 too, so please keep the bug reports coming. The other more esoteric APIs like SQLExtendedFetch() will have to wait... -- cheers, Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From ray@unival.com Tue Nov 25 22:37:33 1997 From: ray@unival.com (ray@unival.com) Date: Tue, 25 Nov 1997 14:37:33 -0800 Subject: [DB-SIG] informix db interface Message-ID: <8825655A.00796F26.00@bilbo.collegenet.com> I am trying to install informixdb. The make appears to complete successfully, but I am getting an error when trying to import informixdb: raise ImportError, "Cannot locate C core module for informix db interface." We are using Informix 7.22, Solaris 2.5 and Python 1.4 Any ideas of what the problem may be? Ray Price _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Fri Nov 28 14:51:43 1997 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Fri, 28 Nov 1997 15:51:43 +0100 Subject: [DB-SIG] ANN: mxODBC Version 0.3 Message-ID: <347EDA7F.3FC7C5B1@uni-duesseldorf.de> The short story: mxODBC is a simple ODBC interface and should work (at least in theory) with any ODBC 2.0 compliant database or ODBC manager. The long one and the ZIP-file to download: http://starship.skyport.net/~lemburg/mxODBC.html Notes: I've finished including the catalog functions, like .tables et al. Also included is a bug fix that caused segfaults when you reuse a cursor and the second execute has more output columns than the first one. Christian Tismer has tried to get the previous version to work under Windows. Unfortunately not with much success. I have fixed a couple of places that should at least make the module compile under VC, but I'm not sure whether I've fixed all of them, since I don't have access to a VC-compiler. Under gcc everything comes out fine and even -Wall is happy. -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From tismer@appliedbiometrics.com Fri Nov 28 20:53:25 1997 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Fri, 28 Nov 1997 21:53:25 +0100 Subject: [DB-SIG] ANN: mxODBC Version 0.3 References: <347EDA7F.3FC7C5B1@uni-duesseldorf.de> Message-ID: <347F2F45.C5684AC0@appliedbiometrics.com> [ introducing V0.3 ] > the first one. Christian Tismer has tried to get the previous > version to work under Windows. Unfortunately not with much success. > I have fixed a couple of places that should at least make the > module compile under VC, but I'm not sure whether I've fixed > all of them, since I don't have access to a VC-compiler. Under > gcc everything comes out fine and even -Wall is happy. Nah, this must have been emails crossing. I got it running perfectly and sent him the ptches yesterday. I'm pretty sure this is a good replacement candidate for the odbc module. I'm going to add the date update which I did for odbc already. If this module proves what it claims, should it be renamed to "odbc" afterwards, or should we live with two versions? cheers - pirx -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Alle 101 : *Starship* http://starship.skyport.net 10553 Berlin : PGP key -> http://pgpkeys.mit.edu we're tired of banana software - shipped green, ripens at home _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From billtut@microsoft.com Fri Nov 28 23:42:33 1997 From: billtut@microsoft.com (Bill Tutt) Date: Fri, 28 Nov 1997 15:42:33 -0800 Subject: [DB-SIG] ANN: mxODBC Version 0.3 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8104536E3@red-msg-50.dns.microsoft.com> Ugh.. why do we need N different ODBC modules? I'd really love to know.. >From your webpage: This interface module was created in need of an Python interface to the German ADABAS D relational database from Software AG. This database can be accessed through the Oracle CLI and or ODBC. After having tried both the OracleDB module from Digital Creations and the SolidDB Module (ODBC) from g.a.m.s. I decided to code my own version, because both didn't meet my requirement for high stability for various reasons. What are those reasons? Please, we'd like to know, really.. :) Also, whats wrong with just porting the ODBC code from Win32? I'm certainly more than willing to answer specific questions about it. Unfortunately I don't have the time to test fixes to it, but I'm more than happy to answer questions about it. Lets see if I can list the differences between your ODBC code, and the Win32 version.. Win32 version has exceptions, where you have essentially ODBC errors.. Exceptions: The dbi code includes exceptions your ODBC module is supposed to throw.. Specfically: noError, opError, progError, integrityError, dataError, and internalError Where they apply to the following cases: noError is generally ment to be thrown when you have a warning i.e. Data truncated that you should know about. opError is an operational error i.e. being disconnected, data source name not found, etc.... progError is a programming error i.e. table already exists, table not found, etc... integrityError is an integirity error in the database's relational integerity i.e. a foreign key check fails dataError is a data error, i.e. Numeric value out of range, division by zero, etc... internalError is an interntal Database error, i.e. Invalid cursor state, invalid transaction state, etc... You have: (sqlstate, sqltype, errortext, lineno) tuples. You can find the sqlstate->DBI exceptions in odbc.cpp in the Win32 code. Autocommit: You default to off, when ODBC defaults to on.. This is highly conterintuitive, and violates the principle of least surprise. The Win32 code has a similar function: setautocommit(0 | 1) to turn autocommit on or off. Whether or not ODBC should default to autocommit or not isn't really the question.. if it does, so should we. Connection String: You have ('host:DBNAME', 'uid', 'pwd') Win32 has: 'DSN/uid/pwd' What really should be done here is to adopt an ODBC like connection string... aka: 'property=value;property=value' Where "uid" is always the userid, and "pwd" is always the password. fetchxxx() return values: The return values are the same as the Win32 ODBC code Ditching DBI: That was a particulary silly thing to do, the exceptions listed above exist in DBI, and DBI is a useful abstraction mechanism, and is database independant.. Why does it need to be tossed? Large Binary/Text data: This is one place where your code does the right thing, and the Win32 ODBC code falls down. Currently the Win32 ODBC code has a 64k limit on binary data, which can be easily fixed. Dates: Well there isn't any difference between what you do, and what the DBI/Win32 ODBC code does. (Well except for handling TIME types but thats just a function of ignoring the date part, or indeed just one line in odbc.cpp) They're both limited to dates after Jan 1, 1970 00:00:00 GMT. What we should do is come up with a sane date type for Python that isn't based on time_t. Looping over lists of tuples for non-resultset producing queries: Your code does do this, and modifying Win32 ODBC to do this is trivial as well. (I have the necessary details btw...) ODBC Catalog functions: Well your code is ahead of the Win32 code here obviously since the Win32 code doens't have anything like this. Submission of code for this kind of thing is greatly appreciated. Wanting only to have one ODBC module, Bill Tutt billtut@microsoft.com Not speaking for Microsoft, etc... _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From gstein@exchange.microsoft.com Sat Nov 29 10:29:41 1997 From: gstein@exchange.microsoft.com (Greg Stein (Exchange)) Date: Sat, 29 Nov 1997 02:29:41 -0800 Subject: [DB-SIG] ANN: mxODBC Version 0.3 Message-ID: <69D8143E230DD111B1D40000F8485840BCB568@ED> Bill makes some good points, but the one single thing that caught my eye last week when you first announced this was your tossing of the DBI module. I'd like to reiterate that that was really not a very good idea (IMO). Exceptions are handled by identity. The single dbi module provides the exception that all db modules will raise. Clients can then catch "dbi.integrityError" and catch an error regardless of what underlying db module was used. The dbi module also provides a common set of type information. As with Bill, I don't understand some of the motivation here... -g p.s. I gave up championing the db-sig because I believe there was nothing left for it to do... that it was a SIG without a purpose. I'd propose that creating a uniform ODBC db module should be placed on the agenda. There was also an "open item" on the agenda for somebody to update/maintain the DBAPI spec; that is still open/undone. -----Original Message----- From: Bill Tutt Sent: Friday, November 28, 1997 3:43 PM To: 'M.-A. Lemburg'; DB-SIG @ Python.org Subject: RE: [DB-SIG] ANN: mxODBC Version 0.3 Ugh.. why do we need N different ODBC modules? I'd really love to know.. >From your webpage: This interface module was created in need of an Python interface to the German ADABAS D relational database from Software AG. This database can be accessed through the Oracle CLI and or ODBC. After having tried both the OracleDB module from Digital Creations and the SolidDB Module (ODBC) from g.a.m.s. I decided to code my own version, because both didn't meet my requirement for high stability for various reasons. What are those reasons? Please, we'd like to know, really.. :) Also, whats wrong with just porting the ODBC code from Win32? I'm certainly more than willing to answer specific questions about it. Unfortunately I don't have the time to test fixes to it, but I'm more than happy to answer questions about it. Lets see if I can list the differences between your ODBC code, and the Win32 version.. Win32 version has exceptions, where you have essentially ODBC errors.. Exceptions: The dbi code includes exceptions your ODBC module is supposed to throw.. Specfically: noError, opError, progError, integrityError, dataError, and internalError Where they apply to the following cases: noError is generally ment to be thrown when you have a warning i.e. Data truncated that you should know about. opError is an operational error i.e. being disconnected, data source name not found, etc.... progError is a programming error i.e. table already exists, table not found, etc... integrityError is an integirity error in the database's relational integerity i.e. a foreign key check fails dataError is a data error, i.e. Numeric value out of range, division by zero, etc... internalError is an interntal Database error, i.e. Invalid cursor state, invalid transaction state, etc... You have: (sqlstate, sqltype, errortext, lineno) tuples. You can find the sqlstate->DBI exceptions in odbc.cpp in the Win32 code. Autocommit: You default to off, when ODBC defaults to on.. This is highly conterintuitive, and violates the principle of least surprise. The Win32 code has a similar function: setautocommit(0 | 1) to turn autocommit on or off. Whether or not ODBC should default to autocommit or not isn't really the question.. if it does, so should we. Connection String: You have ('host:DBNAME', 'uid', 'pwd') Win32 has: 'DSN/uid/pwd' What really should be done here is to adopt an ODBC like connection string... aka: 'property=value;property=value' Where "uid" is always the userid, and "pwd" is always the password. fetchxxx() return values: The return values are the same as the Win32 ODBC code Ditching DBI: That was a particulary silly thing to do, the exceptions listed above exist in DBI, and DBI is a useful abstraction mechanism, and is database independant.. Why does it need to be tossed? Large Binary/Text data: This is one place where your code does the right thing, and the Win32 ODBC code falls down. Currently the Win32 ODBC code has a 64k limit on binary data, which can be easily fixed. Dates: Well there isn't any difference between what you do, and what the DBI/Win32 ODBC code does. (Well except for handling TIME types but thats just a function of ignoring the date part, or indeed just one line in odbc.cpp) They're both limited to dates after Jan 1, 1970 00:00:00 GMT. What we should do is come up with a sane date type for Python that isn't based on time_t. Looping over lists of tuples for non-resultset producing queries: Your code does do this, and modifying Win32 ODBC to do this is trivial as well. (I have the necessary details btw...) ODBC Catalog functions: Well your code is ahead of the Win32 code here obviously since the Win32 code doens't have anything like this. Submission of code for this kind of thing is greatly appreciated. Wanting only to have one ODBC module, Bill Tutt billtut@microsoft.com Not speaking for Microsoft, etc... _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Sat Nov 29 12:13:08 1997 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Sat, 29 Nov 1997 13:13:08 +0100 Subject: [DB-SIG] ANN: mxODBC Version 0.3 References: <69D8143E230DD111B1D40000F8485840BCB568@ED> Message-ID: <348006D4.2E0FB49F@uni-duesseldorf.de> Greg Stein (Exchange) wrote: > > Bill makes some good points, but the one single thing that caught my eye > last week when you first announced this was your tossing of the DBI > module. I'd like to reiterate that that was really not a very good idea > (IMO). > > Exceptions are handled by identity. The single dbi module provides the > exception that all db modules will raise. Clients can then catch > "dbi.integrityError" and catch an error regardless of what underlying db > module was used. The dbi module also provides a common set of type > information. Ok, I'll try to add a Python module named dbi that interfaces to the values defined in mxODBC in just that way, if that's what you are missing [...provided I find time to do so]. I've put that question up before: is there the one and only dbi module that everybody should use, or is this just a naming + content convention that everybody agreed on ? Side note: For ODBC the type information given by the dbi module is not needed. -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Sat Nov 29 11:51:04 1997 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Sat, 29 Nov 1997 12:51:04 +0100 Subject: [DB-SIG] ANN: mxODBC Version 0.3 References: <4D0A23B3F74DD111ACCD00805F31D8104536E3@red-msg-50.dns.microsoft.com> Message-ID: <348001A8.74193719@uni-duesseldorf.de> Bill Tutt wrote: > > Ugh.. why do we need N different ODBC modules? > I'd really love to know.. Don't know if we do... I wrote this code up for my own needs. > >From your webpage: > This interface module was created in need of an Python interface to > the German ADABAS D relational database from Software AG. This database can > be accessed through the Oracle CLI and or ODBC. After having tried both the > OracleDB module from Digital Creations and the SolidDB Module (ODBC) from > g.a.m.s. I decided to code my own version, because both didn't meet my > requirement for high stability for various reasons. > > What are those reasons? > Please, we'd like to know, really.. :) Ok, some explanations: I'm using the Adabas SQL database for a product I'm currently putting together. Since it will run on Un*x, the Win32 odbc module was no option... I knew there was something like this out there, but couldn't find any further information about it and didn't really want to dig into the Win32 Python sources to find it somewhere within. The next step was to try the two other possibilities at the time: Adabas can emulate oracle at API level, so I gave the oracle module from DC a try. That caused several segfaults, either at connect time or shortly thereafter and the errors didn't come out right either -- I don't blame this on the Python module, but on the emulation. Anyway, this was a nogo. Then I considered using the ODBC interface of the database. The only interface I could find was the Solid module that Michael wrote. I tried version 0.0.6 (the latest at that time) and it seemed to work fine except for one thing: LONGs caused regular segfaults. Since I want to save Python pickles in the DB, this posed to be a problem. So I sat down and wrote my own little thingie. And I can tell you, it was fun. Well, until I discovered a bug in the ODBC driver of my database. A workaround is now in place, so that doesn't bother me anymore. High stability: I plan to use the interface for long running processes, which really have to do lots of db stuff. So there are two things to watch out for: segfaults (obviously :) and memory leakage. The second is easy to handle in the normal operation mode, but becomes somewhat tidious in all the different error cases. > Also, whats wrong with just porting the ODBC code from Win32? > I'm certainly more than willing to answer specific questions about it. > Unfortunately I don't have the time to test fixes to it, but I'm more than > happy to answer questions about it. > > Lets see if I can list the differences between your ODBC code, and the Win32 > version.. Before you start: I had a problem finding the "new" DB API mentioned on the web page, in fact I couldn't find it. That's why there opbviously are some things that I didn't know of. Maybe you could point me to the Win32 DB-API ? > Win32 version has exceptions, where you have essentially ODBC errors.. > Exceptions: The dbi code includes exceptions your ODBC module is supposed to > throw.. > Specfically: noError, opError, progError, integrityError, > dataError, and internalError > Where they apply to the following cases: > noError is generally ment to be thrown when you have a warning i.e. > Data truncated that you should know about. > opError is an operational error i.e. being disconnected, data > source name not found, etc.... > progError is a programming error i.e. table already exists, table > not found, etc... > integrityError is an integirity error in the database's relational > integerity i.e. a foreign key check fails > dataError is a data error, i.e. Numeric value out of range, division > by zero, etc... > internalError is an interntal Database error, i.e. Invalid cursor > state, invalid transaction state, etc... > > You have: (sqlstate, sqltype, errortext, lineno) tuples. The lineno component will eventually go away: it's only meant for debugging the code. > You can find the sqlstate->DBI exceptions in odbc.cpp in the Win32 code. I guess I'll have to download the sources after all ;-) > Autocommit: You default to off, when ODBC defaults to on.. > This is highly conterintuitive, and violates the principle of least > surprise. The DB API gave me the impression that you'll always have to explicitly call .commit() to get your changes committed. Now what if someone else also gets this impression and then drops some tables just for the fun it... I'm sure he'd get into a lot of trouble, if the module would have autocommitted his requests. The other way around is less dangerous. > The Win32 code has a similar function: setautocommit(0 | 1) to turn > autocommit on or off. I have exposed the ODBC API setconnectoption() for this to be switched on/off. > Whether or not ODBC should default to autocommit or not isn't really the > question.. if it does, so should we. > > Connection String: > You have ('host:DBNAME', 'uid', 'pwd') > Win32 has: 'DSN/uid/pwd' > What really should be done here is to adopt an ODBC like connection > string... aka: > 'property=value;property=value' Where "uid" is always the userid, and "pwd" > is always the password. But the ODBC API SQLConnect requests those values in exactly that way... why put those three values into one string, when passing them in three seperate strings makes things much clearer. > fetchxxx() return values: > The return values are the same as the Win32 ODBC code Glad to hear that :-) They're not defined in DB API 1.0. > Ditching DBI: > That was a particulary silly thing to do, the exceptions listed above exist > in DBI, and DBI is a useful abstraction mechanism, and is database > independant.. Why does it need to be tossed? I didn't "toss" it, I just didn't need it. If you want it, code it up in Python -- the mxODBC module returns the original and standardized SQL type codes and also exposes these, so wrapping these in a few Python classes really isn't a big deal. The other reason I simply omitted it in the distribution is the fact that I haven't found the "standard" dbi module everybody is referring to. Every DB module seems to have its own, resulting in a unnecessary namespace clash. > Large Binary/Text data: > This is one place where your code does the right thing, and the Win32 ODBC > code falls down. > Currently the Win32 ODBC code has a 64k limit on binary data, which can be > easily fixed. > > Dates: > Well there isn't any difference between what you do, and what the DBI/Win32 > ODBC code does. > (Well except for handling TIME types but thats just a function of ignoring > the date part, or indeed just one line in odbc.cpp) > They're both limited to dates after Jan 1, 1970 00:00:00 GMT. > What we should do is come up with a sane date type for Python that isn't > based on time_t. Hmm, I just thought it would be simple enough interface. Add date and time value and you get what you want. Or simply pass a time.mktime() value. But you're right: dates before 1.1.70 aren't handled well, though they work on Linux: Python 1.5a4 (#165, Nov 19 1997, 22:43:43) [GCC 2.7.2.1] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam i>>> import time >>> time.localtime(time.time()) (1997, 11, 29, 12, 41, 46, 5, 333, 0) >>> time.mktime((1921, 11, 29, 12, 41, 46, 5, 333, 0)) -1517573894.0 >>> time.localtime(_) (1921, 11, 29, 12, 41, 46, 1, 333, 0) >>> > Looping over lists of tuples for non-resultset producing queries: > Your code does do this, and modifying Win32 ODBC to do this is trivial as > well. (I have the necessary details btw...) > > ODBC Catalog functions: > Well your code is ahead of the Win32 code here obviously since the Win32 > code doens't have anything like this. > Submission of code for this kind of thing is greatly appreciated. > > Wanting only to have one ODBC module, Hey, I didn't mean to compete against any other module. On the other hand, a little competition might result in a bright new shining interface for the benefit of all of us ;-) -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From hannu@trust.ee Sat Nov 29 13:50:14 1997 From: hannu@trust.ee (Hannu Krosing) Date: Sat, 29 Nov 1997 15:50:14 +0200 Subject: [DB-SIG] ANN: mxODBC Version 0.3 References: <69D8143E230DD111B1D40000F8485840BCB568@ED> Message-ID: <34801D96.D9008227@sid.trust.ee> Greg Stein (Exchange) wrote: > Bill makes some good points, but the one single thing that caught my eye > last week when you first announced this was your tossing of the DBI > module. I'd like to reiterate that that was really not a very good idea > (IMO). > > Exceptions are handled by identity. The single dbi module provides the Where can one get the abovementioned "single dbi module"? I am in a process of writing a postgres db_module (in pure python, currently runs on both linux and win32, and when Mac version 1.5 is out with its improved struct module I will be able to make it run on Macs as well) and I'm also very interested in such a beast. Until now I have been unable to find the dbi module anywhere. In fact I have'nt even understood if dbi is supposed to be a submodule of my dbmodule (like os.path) or a module that is imported separately. > exception that all db modules will raise. Clients can then catch > "dbi.integrityError" and catch an error regardless of what underlying db > module was used. The dbi module also provides a common set of type > information. Once more, I would very much want to learn where to get the dbi module. Until now I was under an impression that such a module existed only theoretically (in docs) and that everybody should roll his own. That approach of course would produce a lots of incompatible exceptions all called dbi.integrityError ;( Hannu Krosing _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From tismer@appliedbiometrics.com Sat Nov 29 19:10:19 1997 From: tismer@appliedbiometrics.com (Christian Tismer) Date: Sat, 29 Nov 1997 20:10:19 +0100 Subject: [DB-SIG] ANN: mxODBC Version 0.3 References: <69D8143E230DD111B1D40000F8485840BCB568@ED> <34801D96.D9008227@sid.trust.ee> Message-ID: <3480689B.F3B51B63@appliedbiometrics.com> Hannu Krosing wrote: ... > Where can one get the abovementioned "single dbi module"? ... > Until now I have been unable to find the dbi module anywhere. ... I don't know wether it can be found somewhere alone of if it is always included with other DB modules as needed. For sure you can find it in Mark Hammond's source code distribution, in the win32 package. The code is not OS specific. Try http://starship.skyport.net/crew/mhammond/win32_src.zip cheers - pirx -- to Marc Lemburg since I know he will read this: I cannot email to you since days, your .forward from the ship doesn't work. Please change it or call me under +49 30 34902778 -- Christian Tismer :^) Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaiserin-Augusta-Alle 101 : *Starship* http://starship.skyport.net 10553 Berlin : PGP key -> http://pgpkeys.mit.edu we're tired of banana software - shipped green, ripens at home _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From jim@digicool.com Sun Nov 30 18:23:59 1997 From: jim@digicool.com (Jim Fulton) Date: Sun, 30 Nov 1997 13:23:59 -0500 Subject: [DB-SIG] ANN: mxODBC Version 0.3 References: <4D0A23B3F74DD111ACCD00805F31D8104536E3@red-msg-50.dns.microsoft.com> Message-ID: <3481AF3F.4E9B@digicool.com> Bill Tutt wrote: > > Lets see if I can list the differences between your ODBC code, > and the Win32 > version.. > Win32 version has exceptions, where you have essentially ODBC errors.. > Exceptions: The dbi code includes exceptions your ODBC module > is supposed to > throw.. > > Specfically: noError, opError, progError, integrityError, > dataError, and internalError > > Where they apply to the following cases: (snip) This should be part of the DBI spec. It currently isn't. > Autocommit: You default to off, when ODBC defaults to on. These semantics are not documented in the DBI spec, but should be. All database interfaces should provide the same semantics wrt autocommit. IMO, autocommit should default to off. > Connection String: > You have ('host:DBNAME', 'uid', 'pwd') > Win32 has: 'DSN/uid/pwd' (snip) I favor a single connection string, as it increases the similarity between different DB interfaces. > > Ditching DBI: > That was a particulary silly thing to do, the exceptions listed > above exist But are not documented. > in DBI, and DBI is a useful abstraction mechanism, and is database > independant.. > Why does it need to be tossed? I think people may want to toss it because the existing module is not well documented and a bit painful to use. This can be fixed, of course. As has been pointed out, there are several dbi modules around. I had to modify the version that I distributed with oracledb to make it non-windows non-C++ specific. More importantly, the current versions of the dbi module are dynamic-linking unfriendly, especially on non-windows platforms. The dbi module should be modified to use the CObject machinery to export it's C interface to other modules. And of course, as you point out, date-time support is pretty poor. > Dates: > Well there isn't any difference between what you do, and what > the DBI/Win32 ODBC code does. > (Well except for handling TIME types but thats just a function of ignoring the date part, or indeed just one line in odbc.cpp) > They're both limited to dates after Jan 1, 1970 00:00:00 GMT. > What we should do is come up with a sane date type for Python > that isn't > based on time_t. Absolutely. I made some noise about this about a year and a half ago. The discussion was going in a direction that I could not contribute to at the time. Since then, I've come around to a position that is closer to many of the positions advocated at the time. I think there is a more-or-less-standard Date/Time model for many databases. The Spec I'm familiar with is the ODMG-93 spec that includes Date, Time, and TimeStamp. I suspect that these are based on some wider standards, and there are similar looking structs in the ODBC interface (sql.h). I hope to make a proposal based on the ODMG spec in the not too distant future. Unfortunately, I cannot make any promises. :-( Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creattions http://www.digicool.com http://www.python.org _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From lemburg@uni-duesseldorf.de Sun Nov 30 22:13:52 1997 From: lemburg@uni-duesseldorf.de (M.-A. Lemburg) Date: Sun, 30 Nov 1997 23:13:52 +0100 Subject: [DB-SIG] ANN: mxODBC Version 0.3 References: <4D0A23B3F74DD111ACCD00805F31D8104536E3@red-msg-50.dns.microsoft.com> <3481AF3F.4E9B@digicool.com> Message-ID: <3481E520.23081026@uni-duesseldorf.de> Jim Fulton wrote: > > Bill Tutt wrote: > > > > in DBI, and DBI is a useful abstraction mechanism, and is database > > independant.. > > Why does it need to be tossed? > > I think people may want to toss it because the existing > module is not well documented and a bit painful to use. This > can be fixed, of course. > > As has been pointed out, there are several dbi modules around. > I had to modify the version that I distributed with oracledb > to make it non-windows non-C++ specific. > > More importantly, the current versions of the dbi module > are dynamic-linking unfriendly, especially on non-windows > platforms. The dbi module should be modified to use the > CObject machinery to export it's C interface to other modules. Why does it have to be a C module ? I wrote it up as Python module and it works just fine. All the technical stuff is imported from the DB module. > > Dates: > > Well there isn't any difference between what you do, and what > > the DBI/Win32 ODBC code does. > > (Well except for handling TIME types but thats just a function of > ignoring the date part, or indeed just one line in odbc.cpp) > > They're both limited to dates after Jan 1, 1970 00:00:00 GMT. > > What we should do is come up with a sane date type for Python > > that isn't > > based on time_t. > > Absolutely. I made some noise about this about a year and a half ago. > The discussion was going in a direction that I could not contribute to > at the time. Since then, I've come around to a position that > is closer to many of the positions advocated at the time. I think > there is a more-or-less-standard Date/Time model for many databases. > > The Spec I'm familiar with is the ODMG-93 spec that includes Date, > Time, and TimeStamp. I suspect that these are based on some > wider standards, and there are similar looking structs in the > ODBC interface (sql.h). Here is what I propose (which comes pretty close to what you find in sql.h): IMO, the easiest way to support the whole range of possible dates under SQL, is to pass: timestamps as (year,month,day,hour,minute,second,millisecond) dates as (year,month,day) times as (hour,minute,second) as *alternative* to the time value (seconds since epoch). Any string representation would conflict with either the databases current date format settings or the current locale. The version to be used could be set by a cursor.setdatetimeformat(x) method, where x == 0: cursor returns/expects time values as before and x == 1: -"- tuple values as above The corrseponding cursor.getdatetimeformat() method would return the current value. Something else: I have silently updated the mxODBC to version 0.4. It now comes with a dbi-module due to popular demand and also raises the exceptions that Bill mentioned in his recent post. The ODBC catalog functions were already added in 0.3. I also changed the way warnings are returned: up until 0.3 they were silently ignored. Now they result in a noError exception (I consider truncation of data severe enough to give note to the programmer). Though I don't consider "noError" a particularly good name for a "Warning". This is taken from the dbi-module that comes with mxODBC: error = mxODBC.error dataError = mxODBC.DataError integrityError = mxODBC.IntegrityError internalError = mxODBC.InternalError noError = mxODBC.Warning opError = mxODBC.OperationalError progError = mxODBC.ProgrammingError Maybe there's still a chance to have some discussion on the names ? The next version of mxODBC will probably also include the above alternatives for date/time formats. http://starship.skyport.net/~lemburg/mxODBC.html -- Marc-Andre Lemburg _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________ From magnus.lycka@tripnet.se Sun Nov 30 21:46:18 1997 From: magnus.lycka@tripnet.se (Magnus Lycka) Date: Sun, 30 Nov 1997 22:46:18 +0100 Subject: Don't DROP for fun, was:Re: [DB-SIG] ANN: mxODBC Version 0.3 In-Reply-To: <348001A8.74193719@uni-duesseldorf.de> References: <4D0A23B3F74DD111ACCD00805F31D8104536E3@red-msg-50.dns.microsoft.com> Message-ID: <3.0.1.32.19971130224618.007c0100@mail1.tripnet.se> At 12:51 1997-11-29 +0100, M.-A. Lemburg wrote: >The DB API gave me the impression that you'll always have to >explicitly call .commit() to get your changes committed. Now what >if someone else also gets this impression and then drops some >tables just for the fun it... I'm sure he'd get into a lot of >trouble, if the module would have autocommitted his requests. Ouch! He would anyway! SQL is divided into two parts: The data definition languages (DDL) and the data manipulation language (DML) *). The DDL consists of statements that define the database structure such as CREATE and DROP. The DML consists of the statements used in changing and querying database content such as INSERT, UPDATE, DELETE and SELECT. COMMIT and ROLLBACK (and sometimes SAVEPOINT) are used to make multiple DML statements into a single transaction. They do NOT regulate DDL statements. Your DROP TABLE happens at once! At least with the databases I've worked with. (I just tested with Oracle.) Magnus ---- *) Some people would even say that queries aren't manipulation (and I guess that is true) and say that data query language (DQL) is something separate. I.e. SELECT would be DQL, not DML. -- Magnus Lycka, S/W Engineer, M.Sc.E.E; Folktrov. 6C, 907 51 Umea, Sweden Tel: +46(0)90 198 498, GSM: +46(0)70 582 80 65, Fax: +46(0)70 612 80 65 _______________ DB-SIG - SIG on Tabular Databases in Python send messages to: db-sig@python.org administrivia to: db-sig-request@python.org _______________