Re: Which to Use - ProC or OCI ?

From: Ken Frank <ken_at_mn.csoft.com>
Date: 1997/03/21
Message-ID: <33329b62.0_at_news.usinternet.com>#1/1


John Hough <q6y_at_ornl.gov> wrote:
>> Ricardo Rocha (rrocha_at_usagate.net) wrote:
>> : For ease of development and maintenance and (above all) increased
>> : portability, I vote for Pro*C!
>>
>> For configurability of the final software products, I would go with OCI.
>> I have created an DB object using OCI and feel that I have more control
>> over how things function. But again, like Richardo said for ease of
>> development and if you don't have much time to spare go with Pro*C.
 

>Portability is another issue, I am not very familiar with OCI but
>I believe it is proprietary to ORACLE. The Pro*C compiler is
>proprietary also, but almost every dbms has a compiler for embedded
>SQL. Minor changes usually allow this code to be ported to another
>environment.

As someone who is porting a huge amount of Ingres ESQL/C source files over to Oracle Pro*C, I've noticed that roughly 80% of the stuff ports with no trouble at all (once you know how to get things linking, anyways -- thanks to the kind people in this newsgroup).

Unfortunately, the "other 20%" that doesn't port so easily, and takes bloody well forever, because it runs into basic differences in the datatypes supported by the underlying databases. The following things have been causing me the most headaches: * Dates: You'd think they'd be pretty straightforward, but they seem   to be the most sensitive to database dependancies. Ingres allows   dates to "blank" (ie not "null", but when you select it into a char   array, it's nothing but "spaces"), and even some abomination called   a "relative" date (ie, it's value could be "1 month 2 days 3 secs").   Of course, our application made liberal use of both types of date.   Date-arithmetic is also enough different, that I'm now bypassing   the database completely, and calculating whatever I need with   julian dates/times. Talk about re-inventing wheels!

  • Varchar's: Here's one area where I really think Oracle's stupid. Why can't a "blank" varchar/varchar2 be NOT NULL? I believe Sybase has the same restriction as well, but it sure seems pretty ridiculous to me. (For what it's worth, this is actually less of a problem in 'C' than in our hideous 4gl language [CA-OpenRoad]). Another problem area has been comparing chars/varchars -- our code was pretty sloppy because Ingres ignores trailing spaces when it compares them in where-clauses.

My opinions only!
Ken Frank Received on Fri Mar 21 1997 - 00:00:00 CET

Original text of this message