Re: Pro*C and C++

In article <2pft6n$gfi_at_tibalt.supernet.ab.ca>, forbrich_at_tibalt.supernet.ab.ca (Hans Forbrich) writes:
|> Globules (globules_at_aol.com) wrote:
|> > In article <2p465e$s16_at_news.cerf.net>, itsinet_at_nic.cerf.net (John Roesch)
|> > writes:
 

|> > We are considering using CenterLine C++ and PRO*C from
|> > ORACLE on an HP 9000. My contract insists that we develop
|> > an 'open system' that is portable to other database environments.
|> > One of our options is to develop embedded SQL calls in
|> > our C++ code and use PRO*C to compile the SQL. Is this approach an open
|> > system? My understanding is that PRO*C is proprietary. Can I later transfer
|> > to SYBASE without a lot of reworking?
 

|> > Thanks for any feedback. Jim O'Connell.
|>
|> So far, I have not seen any non-proprietary method of calling SQL
|> databases from C (or any other 3GL). My, admittedly limited,
|> understanding of ODBC indicates that special calls may be passed
|> through to the RDBMS untranslated - allowing the RDBMS' ANSI
|> variants to shine through.
|>
|> PLEASE CORRECT ME IF I AM WRONG!
|>
|> In the mean time, I strongly suggest that Pro*C segments be
|> kept in their own modules. Until the standard actually becomes
|> standardized this may be the only safe bet.
|>
|> Also, ODBC is getting close to being a vendor independant and
|> platform independant product (I think Q+E has announced that
|> their ODBC is/will be available on UNIX, etc.), but compared
|> to Pro*C, it's a bear. It's similar in taste to OCI - bittersweet.
|>
|> /Hans
|>
|> ----------------------------------------------------------------------
|> Hans Forbrich | Certainly the game is rigged. Don't
|> forbrich_at_tibalt.supernet.ab.ca | let that stop you; if you don't play
|> Compuserve: 72613,2042 | you can't win.
|> | - from the Notebooks of Lazarus Long
|> ----------------------------------------------------------------------
|>
|>
|>

The only "open" way to access database systems is through the X/Open API, which is supported by Oracle and Sybase (and I think Ingres and DB2). My limited experience with this API indicates that it has a negative performance impact, but it is standard and RDBMS-independent (which are the general tests of openness).

-- 
Derek Fields
(derek_at_gamekeeper.bellcore.com)