Re: Pro*C and OCI
Date: 1995/11/01
Message-ID: <enduser-0111951634370001_at_204.247.5.21>#1/1
Proc*C is a higher level interface and is not buggy. you need to writel lower level code in fear of debugging Pro*C is not warranted. OCI is really appropriate when writing device drivers and other callable routines in support of embedded products where performance is the highest goal, and bit twiddling is necessary for what you are doing. Pro*C is appropriate in almost all other circumstatnce, you shouldnt consider using OCI for ordinary apps that access the database.
In article <NEWTNews.815186338.30841.steve_at_excal.gate.net>, Steve Preisach <steve_at_mailhost.gate.net> wrote:
> In Article<471n9r$j1l$1_at_mhade.production.compuserve.com>,
> <75533.1104_at_CompuServe.COM> write:
> > Path:
> gate.net!news.sprintlink.net!newsserver.pixel.kodak.com!bloom-beacon.mit.e
>
> >
> > Could somebody tell me what the advantage of using Pro*C
> > pre-processor is as oppose to making direct OCI calls to develop
> > software using Oracle. Why would I want to go through another
> > step of pre-processing a file and trying to debug a generated
> > code? I realize that the ideal is to write "portable" embedded
> > sql code so that the code one writes become easily portable to
> > another DBMS vendor but how true is this? Is it worth a hassle?
> > Isn't there a lot of work in porting softwares from one DBMS to
> > another no matter what method you're using to write your software?
> > Any comments would be appreciated...
>
>
> I have found the issue is not portability, but convenience. Using Pro*C
> instead of OCI calls is significantly easier. You wind up with C and
> embedded SQL. It is quite easy to maintain. The only time I have had to
> look at the generated code is to determine how the VARCHAR2 structure was
> implemented, so my code was compatible. (and to find which line in the
> generated C code the compiler was throwing out. It's always been my
> fault.)
Received on Wed Nov 01 1995 - 00:00:00 CET