Re: !! Pro*C versus OCI !!

Just to make a point here, the precompilers do NOT generate OCI code. The precompilers (Pro*C) generate calls to libsql.a, which is similar to, but different from, libocic.a. The two libraries have different functionality (such as the non-blocking OCI which will be in 7.2, available only in OCI as of yet).

In article <3dutea$8al_at_dcsun4.us.oracle.com>, dchatter_at_us.oracle.com (Debu Chatterjee) writes:
|> In article <3dup6t$2uq_at_hustle.rahul.net> Edwin Kuprienko <ekuprien_at_rahul.net> writes:
|> >The main difference is that if OCI library is changed/updated the PRO*C
|> >compiler wil automatically take advantage of it without rewriting your
|> >code. You just need to recompilusing new version of PRO*C.
|> >
|> >Additionally PRO*C seems to be a standard while OCI is a hacker's approach.
|> >
|> >I found that C programmers prefer to use OCI function calls then use
|> >embeded SQL. However once they get used to the concept, it doesn't matter
|> >that much. Personally I prefer PRO*C.
|> >
|> >I don't think however, that Oracle OCI is changed very often, but in the
|> >long run it can save couple of headaches.
|> >
|> > Edwin Kuprienko
|> >
|> >
|> >Dennis Harvey (harvey_at_metropolis.com) wrote:
|> >: Our company is presently porting one of our commercial applications
|> >: from Sybase (OpenClient/DB-Library) to Oracle. I am inclined to go
|> >: with the call level interface (OCI) rather that the precompiled
|> >: approach (Pro*C). The OCI approach has the advantages of eliminating
|> >: the need for the precompiler, and is easier to debug. Are there any
|> >: compelling advantages to using the Pro*C approach? I appreciate any
|> >: opinions or help I can get on this.
 

|> >: Dennis Harvey
|> >: Metropolis Software Inc.
|> >: harvey_at_metropolis.com
|> >
|> >--
|> >------------------------------------------------------------
|> >| Whatever goes up has to go down. |
|> >| Whatever goes down will very likely stay that way. |
|> >------------------------------------------------------------
|>
|>
|> OCI library is always backward compatible. You will never have to rewrite an
|> existing code to work with a new library. New calls are added to OCI to add
|> new functionality which does existing things better or provides features not
|> available but preferred. Existing calls are never changed for that reason, and
|> new calls are added. There is proliferation of calls doing similiar stuff for
|> that reason.
|>
|> If existing calls do not work then it is a bug and should be reported.
|> However, much care is taken to see that existing calls always work in the new
|> library.
|>
|> Pro*C/.. are never always kept in sync with changes in OCI functionality. The
|> code to provide Embedded SQL functionality is never automatically upgraded to
|> use the new calls. However they use the new OCI library, but not the new
|> functionalities in the library. It is a myth that Pro*.. compilers will
|> automatically take the advantage of an upgraded OCI library.
|>
|> If you have Oracle 7.2, you will not be able to use non-blocking feature of OCI
|> in Pro*C. This is one of the examples how Pro*.. is not upto-date with OCI.
|>
|> If you are comfortable with C, I would strongly advise you to use OCI, as it is
|> like driving a stick shift, you have the power in your hands.
|>
|>
|> Debashish Chatterjee
|>
|>
|> Disclaimer: Opinions expressed are mine and does not reflect the official
|> company policies or views.
Received on Thu Dec 29 1994 - 19:43:01 CET