tamaru@csl.sri.com (Ann Tamaru) (11/16/89)
Does anyone out there still actively use Oracle's OCI (Oracle Call Interface) for their application development? We are currently debating on whether to use this programmatic interface or the "newer" Pro*C interface (embedded SQL). The former is favorable due to its flexibility (and possibly more efficient?), but the latter seems quicker to develop programs with. Also, it seems that the latter has better technical support coverage, which leads me to think that OCI may be phased out in the near future...? Thanks in advance for any responses, Ann Tamaru
rwb@viusys.uucp (Rick Butland) (11/17/89)
In article <13485@hercules.csl.sri.com> tamaru@csl.sri.com (Ann Tamaru) writes: >Does anyone out there still actively use Oracle's OCI (Oracle Call Interface) >for their application development? We are currently debating on whether to >use this programmatic interface or the "newer" Pro*C interface (embedded SQL). >The former is favorable due to its flexibility (and possibly more efficient?), >but the latter seems quicker to develop programs with. Also, it seems that >the latter has better technical support coverage, which leads me to think that >OCI may be phased out in the near future...? > Obviously I don't speak for Oracle, but I've heard that OCI will be phased out when the precompiler interface (Pro*C) is as capable as the OCI. I really don't have any reason to disbelieve that as supporting two different products with essentially the same function is a waste. Personally, I've always recommended to my customers that they use the Pro*C interface for the reasons that you cite, namely better technical support, and the ease-of-use considerations. If they ever encounter a situation where they need some functionality that only OCI can provide, then learn and use OCI to fulfill that need. I think that Pro*C covers most requirements. As for efficiency, you're probably right, I'd tend to believe that OCI is more efficient than Pro*C, but I really haven't evaluated that in any depth. I personally feel that, in most cases, the efficiency (possibly) lost is more than made up for by the gains in programmer productivity. CPU time is cheap, programmer's time is not. Rick
dgh@unify.UUCP (David Harrington) (11/18/89)
In article <13485@hercules.csl.sri.com> tamaru@csl.sri.com (Ann Tamaru) writes: >Does anyone out there still actively use Oracle's OCI (Oracle Call Interface) >for their application development? We are currently debating on whether to >use this programmatic interface or the "newer" Pro*C interface (embedded SQL). >The former is favorable due to its flexibility (and possibly more efficient?), >but the latter seems quicker to develop programs with. Also, it seems that >the latter has better technical support coverage, which leads me to think that >OCI may be phased out in the near future...? > >Thanks in advance for any responses, >Ann Tamaru Why not try Accell/SQL from Unify? We have just announced Accell/SQL for Oracle, with immediate availability. Accell/SQL is the leading (IMHO) Unix 4GL and application generator. It combines a screen-based WYSIWYG forms generator with a sophisticated event driven and procedural 4GL, with full SQL functionality and more. It now runs on Oracle 5.x and 6.0. I think Accell/SQL would be a much better decision than OCI or Pro*C, and you can use C programs with Accell/SQL. David Harrington Director, Accell Development
ltung@oracle.com (Lei Tung) (11/18/89)
In article <24@viusys.UUCP> rwb@viusys.uucp (Rick Butland) writes: > Obviously I don't speak for Oracle, but I've heard that OCI will be > phased out when the precompiler interface (Pro*C) is as capable as the > OCI. Oracle's call interface (OCI) will NOT be phased out anytime in the foreseeable future. There is no reason to since it is such a thin layer above Oracle's User Program Interface (UPI) layer which is obviously here to stay. OCI will continue to be supported for C and FORTRAN (at least). There are uncountable applications written in OCI out in the field. They will not be left hanging. > I really don't have any reason to disbelieve that as supporting two > different products with essentially the same function is a waste. OCI is far less than a product, just a few simple hooks into the UPI. > Personally, I've always recommended to my customers that they use the > Pro*C interface for the reasons that you cite, namely better technical > support, and the ease-of-use considerations. Agreed. > If they ever encounter a situation where they need some functionality > that only OCI can provide, then learn and use OCI to fulfill that > need. The situations that I've encountered where PCC breaks down have been when recursion is involved, or when the user needs very fine control over cursors (for instance, pushing then onto a stack). > I think that Pro*C covers most requirements. As for efficiency, > you're probably right, I'd tend to believe that OCI is more efficient > than Pro*C, but I really haven't evaluated that in any depth. In most cases embedded SQL (and PCC) will produce object code which is just as efficient as good OCI code (if you overlook the UGLINESS of the generated C or FORTRAN code). Again, if you need absolute control over when cursors are allocated, parsed, bound (variables), and executed then you may want to use OCI. PCC does a good job (if you use the EXEC SQL options wisely), but you never know EXACTLY which UPI calls it will make. > I personally feel that, in most cases, the efficiency (possibly) lost > is more than made up for by the gains in programmer productivity. CPU > time is cheap, programmer's time is not. Very true. This is how we feel also. Hope this helps, Lei Tung Unix Development Oracle Corp. -- *------------------------------------------------------------------------* | email: ltung@oracle.com | | or: {hplabs,apple,pacbell,mit-eddie,uunet}!oracle!ltung | | | | It'll all work out, | | you know I'm a little freaked out . . . | | - D. B. | *------------------------------------------------------------------------*
sullivan@aqdata.uucp (Michael T. Sullivan) (11/18/89)
From article <1285@unify.UUCP>, by dgh@unify.UUCP (David Harrington): > > Why not try Accell/SQL from Unify? We have just announced Accell/SQL for > Oracle, with immediate availability. > > ... <ad nauseum> Is this really the place to make a sales pitch? Couldn't email have been more effective? -- Michael Sullivan uunet!jarthur.uucp!aqdata!sullivan aQdata, Inc. San Dimas, CA
tim@binky.sybase.com (Tim Wood) (11/21/89)
In article <1285@unify.UUCP> dgh@unify.UUCP (David Harrington) writes: >In article <13485@hercules.csl.sri.com> tamaru@csl.sri.com (Ann Tamaru) writes: >>Does anyone out there still actively use Oracle's OCI (Oracle Call Interface) >>for their application development? >>Ann Tamaru > >Why not try Accell/SQL from Unify? [...] > >Accell/SQL is the leading (IMHO) Unix 4GL and application generator. [...] > >I think Accell/SQL would be a much better decision than OCI or Pro*C [...] > >David Harrington >Director, >Accell Development I tried to e-mail this reply, but it bounced. (DH- would you include a bang-path in your .signature? Not everyone can resolve the @unify.UUCP) The commercial tone of your posting is not appropriate to comp.databases. It would be better suited to comp.newprod or one of the biz. groups. Comp.databases is a technical forum, not intended for product announcements or marketing. IMO, your message would be more relevant if you turned it around: demonstrate why the features are technically superior, then mention that Accell has them. If you can convince me that your product does intelligent things, I'd be more disposed to it than if you start off saying "buy this because ... I'm the development director and I like it." At least I'd understand what it does that brands X and Z don't. And I'd be better able to evaluate up front whether the product is compatible with my application. -TW Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608 415-596-3500 tim@sybase.com {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim This message is solely my personal opinion. It is not a representation of Sybase, Inc. OK.
lchirica@polyslo.CalPoly.EDU (Laurian Chirica) (11/21/89)
>> >> Why not try Accell/SQL from Unify? We have just announced Accell/SQL for >> Oracle, with immediate availability. >> >> ... <ad nauseum> > >Is this really the place to make a sales pitch? Couldn't email have >been more effective? This is not inteded to be a flame of any kind, but personally, I found the information that Accell/SQL is available *NOW* very useful. As a matter of fact the information was very timely since I am involved in choosing a 4GL for a number of future application, some of them involving ORACLE. the middle of deciding on a 4GL for a number of ORACLE datana -- Laurian M. Chirica (lchirica@polyslo.calpoly.edu) Computer Science Department ..!ucbvax!voder\ California Polytechnic State University ..!sdcrdcf!csun |!polyslo!lchirica San Luis Obispo, CA 93407 (805)756-1332 ..!lll-crg!csustan/