RE: Stored procedures that return multiple rows
Paul, Our applicationsdo database access solely though packaged pl/sql calls which return a ref cursor. Some use OCI, others JDBC. Experience has been very positive. Administrative advantages in having such an "abstraction layer" between apps and the database are manifold As a DBA, you have a lot of leeway to change things around on the back end w/o breaking the app. One drawback to the approach is that it requires more up-front planning on the app developers to identify the database calls. James Turner DBA Unplugged Games -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Paul BaumgartelSent: Thursday, August 23, 2001 4:11 PMTo: Multiple recipients of list ORACLE-LSubject: Stored procedures that return multiple rows We're considering a mandate that all database access be via stored procedures (probably in packages). These would becalled eithervia OCCI (the C++ call interface) or JDBC. Myquestion is whether anyone's had experience in returninga result set from a PL/SQL procedure under thesecircumstances, and how it was implemented:did you return a ref cursor, an index-by table, a set of arrays? Any advice will be appreciated. Thanks! Paul Baumgartel MortgageSight Holdings, LLC [EMAIL PROTECTED]
RE: Stored procedures that return multiple rows
On my previous gig all DB access was via stored procedures returning ref cursors through JDBC. The Java dweebs could do just about anything with the ref cursor. It worked really well. I could actually tune SQL queries on the running production application without any recompilation. Nice seperation of code. The DBA can tune real SQL code and the developers won't even know. No embedded SQL. Yeah!! OCI can also accommodate ref cursors. Steve Orr -Original Message-From: Paul Baumgartel [mailto:[EMAIL PROTECTED]]Sent: Thursday, August 23, 2001 2:11 PMTo: Multiple recipients of list ORACLE-LSubject: Stored procedures that return multiple rows We're considering a mandate that all database access be via stored procedures (probably in packages). These would becalled eithervia OCCI (the C++ call interface) or JDBC. Myquestion is whether anyone's had experience in returninga result set from a PL/SQL procedure under thesecircumstances, and how it was implemented:did you return a ref cursor, an index-by table, a set of arrays? Any advice will be appreciated. Thanks! Paul Baumgartel MortgageSight Holdings, LLC [EMAIL PROTECTED]
RE: Stored procedures that return multiple rows
Paul, For acouple of projects that I've worked on, several Java programmers have liked having Ref Cursors returned from PL/SQL stored procedures. They could work with those much more easily than PL/SQL tables. Can't remember if we even tried VArrays. I don't think I'd like them for returning table data - too much work to populate them. Jack Jack C. ApplewhiteDatabase Administrator/DeveloperOCP Oracle8 DBAiNetProfit, Inc.Austin, Texaswww.iNetProfit.com[EMAIL PROTECTED](512)327-9068 -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Paul BaumgartelSent: Thursday, August 23, 2001 3:11 PMTo: Multiple recipients of list ORACLE-LSubject: Stored procedures that return multiple rows We're considering a mandate that all database access be via stored procedures (probably in packages). These would becalled eithervia OCCI (the C++ call interface) or JDBC. Myquestion is whether anyone's had experience in returninga result set from a PL/SQL procedure under thesecircumstances, and how it was implemented:did you return a ref cursor, an index-by table, a set of arrays? Any advice will be appreciated. Thanks! Paul Baumgartel MortgageSight Holdings, LLC [EMAIL PROTECTED]
RE: Stored procedures that return multiple rows
I was about to write a similar testimonial when I saw Steve Orr's message. Don't use OCI based class111.zip. It has Oracle properity classes. The pure java class111.zip works great and is portable. Passing ref cursors from stored procedures makes the solution simple and elegent to implement. The seperation between the client rendering (HTML/Javascript/XML crowd) and middle tier Java servlets and Middle tier and RDBMS developer (using ref cursors over thin JDBC) is perhaps the best way to go. Avoid embeded SQL in Java if possible. Access to RDBMS via ref_cursor hides the DB schema from the Java developers making DB schema changes less painful and also allowing future switch of the databases if required, lot less painful. No meddling from Java folks too. I don't know how anybody decides on application partitioning issues as this division between business/domain objects and their persistence in the database raises all sorts of interesting design issues Regds --- Orr, Steve [EMAIL PROTECTED] wrote: On my previous gig all DB access was via stored procedures returning ref cursors through JDBC. The Java dweebs could do just about anything with the ref cursor. It worked really well. I could actually tune SQL queries on the running production application without any recompilation. Nice seperation of code. The DBA can tune real SQL code and the developers won't even know. No embedded SQL. Yeah!! OCI can also accommodate ref cursors. Steve Orr -Original Message- Sent: Thursday, August 23, 2001 2:11 PM To: Multiple recipients of list ORACLE-L We're considering a mandate that all database access be via stored procedures (probably in packages). These would be called either via OCCI (the C++ call interface) or JDBC. My question is whether anyone's had experience in returning a result set from a PL/SQL procedure under these circumstances, and how it was implemented: did you return a ref cursor, an index-by table, a set of arrays? Any advice will be appreciated. Thanks! Paul Baumgartel MortgageSight Holdings, LLC [EMAIL PROTECTED] = Sundeep Maini Consultant Currently on Assignement at Marshfield Clinic WI [EMAIL PROTECTED] __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: sundeep maini INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
